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Technology  Transition  Pull: 

A  Case  Study  of  Rate  Monotonic  Analysis  (Part  2) 

Abstract:  This  case  study  reports  on  efforts  to  introduce  a  software 
technology,  rate  monotonic  analysis,  into  several  software-intensive  programs 
at  one  site  within  a  multinational  firm.  We  describe  lessons  learned  and 
success  factors  In  the  early  use  of  rate  monotonic  analysis  (RMA).  We  also 
present  evidence  that  supports  the  requirement  for  an  internal  capability— in 
the  form  of  technical  expertise  and  infrastructure— to  adopt  and  assimilate  this 
new  technology.  Finally,  the  study  applies  the  “whole  product”  concept  for 
understanding  technology  adoption  and  use,  showing  how  one  firm 
compensated  for  lack  of  a  whole  product  in  its  adoption  of  RMA. 


1  Introduction 

The  acquisition  and  introduction  of  new  software  technologies  (including  tools,  methods,  and 
management  approaches)  is  so  much  a  part  of  most  software  development  and  maintenance 
efforts  that  we  do  not  even  call  it  out  as  a  separate  activity.  However,  one  reasonable  expla¬ 
nation  for  why  cost  and  schedule  overruns  are  so  common  in  software  projects  is  the  continual 
learning  required  on  the  part  of  software  engineers  and  managers.  One  solution  to  the  soft¬ 
ware  “crisis”  [Gibbs,  1994]  is  to  better  understand  and  anticipate  problems  and  barriers  in  the 
introduction  of  new  software  technologies,  such  as  rate  monotonic  analysis  (RMA),  which  is 
the  subject  of  this  report.  [This  is  also  the  focus  of  the  Transition  Models  Project  at  the  Soft¬ 
ware  Engineering  Institute  (SEI).]^ 

RMA  is  a  simple,  practical,  mathematically  sound  way  to  guarantee  that  all  timing  require¬ 
ments  will  be  met  in  software-intensive  real-time  systems.  RMA  allows  engineers  to  under¬ 
stand  and  predict  the  timing  behavior  of  real-time  software  to  a  degree  not  previously  possible. 
The  Rate  Monotonic  Analysis  for  Real-Time  Systems  (RMARTS)  Project  at  the  SEI  has  dem¬ 
onstrated  howto  design,  implement,  troubleshoot,  and  maintain  real-time  systems  using  RMA. 
From  1987-1992,  the  project  worked  to  develop  the  technology  and  encourage  its  widespread 
use  to  reduce  risk  in  building  real-time  systems.  This  report,  which  is  Part  2  of  a  two-part  case 
study,  describes  how  several  projects  in  one  organization  attempted  to  adopt  and  apply  RMA 
technology.  Of  particular  interest  is  how  an  innovative  culture  and  an  organization’s  willing¬ 
ness  to  act  as  a  co-developer,  and  an  existing  infrastructure  for  software  technology  transition, 
compensated  for  missing  aspects  of  the  whole  product  [Moore,  1991].  A  whole  product,  ac¬ 
cording  to  Moore,  is  a  product  that  incorporates  the  adjunct  products  and  services  that  are 
necessary  for  popularization  (i.e.,  training  and  support,  courses,  documentation,  handbooks). 

The  study  of  the  maturation  of  RMA  is  one  part  of  a  larger  effort  to  build  a  “thick  description”  [Geertz,  1972]  of 
software  technology  transition.  (Such  an  ethnographic  description  makes  the  tacit  explicit;  attends  to  cultural 
practice,  including  communication  in  a  given  community,  organization,  or  group;  attends  to  detail  and  not  only 
abstract  concepts;  and  captures  language  as  it  is  in  use — as  it  reveals  the  values  and  priorities  of  those  groups.) 
Additional  work  in  the  Transition  Models  Project  explores  related  levels  of  analysis:  for  example,  Fowler  &  Levine 
[1993]  offer  a  conceptual  framework  for  technology  transition,  from  the  birth  of  a  technology  to  its  retirement. 
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The  investigation  of  RMA  development  and  transition  is  intended  to  make  a  twofold  contribu¬ 
tion  to  greater  understanding  of  technology  transition.^  Our  aim  is  to  encourage  researchers 
to  further  explore  the  precepts  presented  here  with  respect  to  other  software  technologies  and 
to  help  practitioners,  developers,  and  transition  agents  alike,  learn  from  the  strategies  used  by 
teams  such  as  RMARTS.  In  addition,  for  researchers  and  practitioners  to  better  understand 
technology  transition,  they  must  look  beyond  development  perspectives  to  examine  the  expe¬ 
riences  of  populations  who  attempt  to  adopt  and  impiement  software  technoiogy.  People  work¬ 
ing  in  the  area  of  software  technology  transition  should  be  able  to  make  practical  adaptations 
of  the  heuristics  and  iessons  identified  here  for  their  own  contexts.  The  case  study  approach 
is  a  good  match  for  our  double  purpose:  the  research  method  allows  for  close  examination  and 
interpretation,  and  the  rich  and  detailed  form  can  provide  practitioners  with  surrogate  experi¬ 
ence  of  a  complex  transition  situation. 

As  indicated,  the  case  study  consists  of  two  technicai  reports:  Part  1  (CMU/SEI-93-TR-29)  is 
concerned  with  the  analysis  of  RMA  transition  activities  according  to  phases  of  a  technology 
maturation  life  cycle;  Part  2  (this  report)  investigates  the  processes  of  RMA  adoption  and  im¬ 
plementation  at  ComCo,^  Woodville.^  Together,  the  two  parts  allow  us  to  attend  to  develop¬ 
ment  and  user  perspectives — or  more  colloquially  put,  to  technology  push  and  technology  pull. 
Part  2  of  the  case  study  includes  these  sections: 

•  A  brief  description  of  RMA  (Section  2,  page  5). 

•  The  rationale  for  selecting  it  as  a  topic  of  study  (Section  3,  page  9). 

•  Research  method  and  procedure  (Section  4,  page  17). 

•  Results  (Section  5,  page  23). 

•  Implications  for  those  managing  software  technology  transition  and 
directions  for  future  research  (Section  6,  page  53). 


The  phrase  “technology  transfer"  is  usually  preferred,  except  within  the  DoD.  For  the  purposes  of  this  report,  we 
consider  “technology  transfer,”  “technology  transition,”  and  “technology  deployment”  to  be  synonymous.  In  addi¬ 
tion,  we  agree  with  Tornatzky  &  Fleischer  [1990]:  “Technology  transfer,  while  a  commonly  used  term,  has  a  host 
of  nuances,  not  the  least  of  which  is  the  image  that  technology  is  something  that  is  physical,  comes  in  large  crates 
or  on  pallets,  and  gets  literally  moved  from  place  to  place.”  On  this  basis,  they  “use  the  more  inclusive  and  less 
encumbered  notion  of  deployment"  \p.  118;  italics  Tornatzky  &  Fleischer];  we  prefer  “technology  transition.” 

3-  Pseudonym  for  the  firm  name.  ComCo  is  a  multinational  firm  in  electronics  and  related  businesses. 

*■  Pseudonym  for  the  name  of  the  site  where  we  held  our  interviews. 
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The  data  used  for  Part  2  were  derived  from  interviews  with  10  members  (affiliated  with  2  de¬ 
partments,  3  projects,  and  one  advanced  technical  solutions  group)  at  one  site  in  one  large 
organization.  All  of  these  individuals  had  some  knowledge  of,  and  experience  with,  the  use  of 
RMA  technology.  Interview  findings  are  discussed  in  terms  of  relevant  themes  including 

•  Roles  and  key  players 

•  Infrastructure 

•  Innovative  culture 

•  Technology  attributes 

•  Concept  of  the  whole  product 
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2  Rate  Monotonic  Analysis 


RMA  helps  software  engineers  who  are  designing,  building,  troubleshooting,  and  maintaining 
real-time  systems  to  understand  and  predict  the  timing  behavior  of  hard  real-time  systems  to 
a  degree  not  previously  possible.  Real-time  systems  are  often  seen  as  a  “niche”  within  the 
software  world,  but  they  are  a  critical  niche.  Real-time  software  is  often  embedded  in  life-crit¬ 
ical  systems  such  as  avionics  and  other  transportation  systems;  medical  systems  such  as 
equipment  for  patient  monitoring,  diagnosis,  and  treatment;  and  process  control  systems  in 
chemical  processing  and  nuclear  power  plants. 

In  the  software  embedded  in  such  real-time  systems,  multiple  tasks  contend  for  the  use  of  a 
finite  amount  of  resource— for  example,  of  the  central  processing  unit  (CPU)  to  perform  work 
within  deadlines.  Typically,  these  tasks,  such  as  monitoring  altitude,  monitoring  cabin  pres¬ 
sure,  or  controlling  fuel  injection  level  on  an  aircraft,  are  of  differing  priorities  and  require  dif¬ 
ferent  amounts  of  CPU  effort  to  complete  their  work.  These  tasks  can  occur  both  at  regular 
intervals  and  irregularly.  Real-time  systems  must  complete  critical  tasks  (for  example,  the  low¬ 
ering  of  the  landing  gear)  by  particular  deadlines,  or  place  the  entire  system  at  risk.  Without 
the  appropriate  handling  of  schedules  and  priorities,  a  lower  priority  task  of  relatively  long  du¬ 
ration — ^for  example,  intermittent  monitoring  of  passenger  cabin  pressure — can  monopolize 
the  CPU  at  the  expense  of  a  critical  task. 

Traditionally,  the  approach  to  calculating  appropriate  task  mixes  has  been  by  trial  and  error. 
Programs  are  written  to  accomplish  the  required  tasks,  but  until  the  tasks  are  integrated  into 
a  system  and  tested  as  a  system,  there  is  no  way  to  know  whether  all  tasks  can  be  accom¬ 
plished  within  the  constraints  of  the  available  CPU.  Most  often  deadlines  are  not  met  until  after 
many  iterations  of  integration  testing,  program  revision,  and  more  testing.  For  these  reasons, 
real-time  systems  have  earned  the  reputation  of  being  expensive,  behind  schedule,  risky,  and 
difficult  to  maintain. 

While  the  traditional  approach  is  manageable  for  simple  systems,  especially  when  particular 
system  designers  have  become  expert  in  the  successful  design  of  task  mixes,  it  is  unmanage¬ 
able  for  large  systems.  As  large  real-time  systems  are  increasingly  built  from  commercial  “off- 
the-shelf  or  separately  contracted  subsystems,  handcrafting  of  scheduling  is  increasingly 
risky.  Rate  monotonic  scheduling  theory  and  its  related  analytical  method,  RMA,  provide  a  sci¬ 
entific  approach  that  can  be  used,  before  system  integration,  to  determine  whether  schedule 
requirements  can  be  met  and  how  well,  and  under  what  conditions  task  completion  can  be 
guaranteed.®  Because  RMA  solves  a  difficult  problem  early  in  the  development  of  a  real-time 
system,  it  is  an  important  innovation  with  respect  to  technical  work  and  its  management — it 
can  result  in  significant  savings  not  only  of  CPU  resources  but  potentially  of  both  system  de¬ 
velopment  resources,  including  schedule,  and  operational  resources  such  as  hardware. 

The  early  focus  of  RMA  ensured  that  as  long  as  CPU  resource  utilization  was  below  a  certain  bound  (generaliy 
a  percentage  of  total  possible  resource),  all  the  timing  requirements  would  be  met  [Sha  &  Goodenough,  1990], 
More  recently,  the  focus  of  RMA  has  shifted  to  computing  the  worst-case  response  time  and  comparing  it  to  the 
response  time  requirement. 
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2.1  Rationale  and  Background 

studying  the  transition  of  software  technologies  is  difficult  for  a  number  of  reasons.  First,  the 
process-intensive  nature  of  software  technologies  means  that  there  is  a  complex  interaction 
between  the  social  context  and  the  technical  content  of  the  technology  [Tornatzky  &  Fleischer, 
1990].  More  specifically,  technology  introduction  affects  not  only  the  technical  subsystem,  but 
the  managerial,  strategic,  human,  and  cultural  subsystems  as  well  [Morgan,  1986].  The  chal¬ 
lenge  of  studying  transition  in  an  organizational  setting  is  well  acknowledged  [Nord  &  Tucker, 
1987;  Yin,  1984]. 

In  the  previous  section  we  described  the  technical  characteristics  of  RMA.  However,  it  is 
equally  important  to  attend  to  the  implementation  characteristics  of  a  technology  [Leonard- 
Barton,  1988a:  Leonard-Barton,  1988b;  Rogers,  1983;  Tornatzky  &  Klein,  1982].  Three  such 
characteristics— complexity  (size),  observability,  and  maturity— were  critical  factors  in  our  de¬ 
cision  to  study  RMA.  We  discuss  each  of  these  in  turn.  We  then  briefly  describe  other  aspects 
of  RMA’s  circumstances  that  led  us  to  choose  to  study  Its  transition  process. 

2.1.1  Size 

Rogers  [1983]  defines  complexity  as  “the  degree  to  which  an  innovation  is  perceived  as  rela¬ 
tively  difficult  to  understand  and  use”  (p.  230).  Another  way  to  decompose  the  issue  of  com¬ 
plexity  is  to  look  at  technologies  in  terms  of  their  breadth  of  impact  in  an  organization  [Adler  & 
Shenhar,  1990].  According  to  Adler  &  Shenhar,  adopting  a  technology  that  will  change  skills 
and  procedures  typically  requires  only  the  space  of  weeks;  in  contrast,  adopting  a  technology 
involving  a  change  in  either  structure  or  strategy  requires  months  of  planning  and  implemen¬ 
tation.  When  we  selected  RMA  for  study,  based  on  descriptions  from  its  developers,  we  be¬ 
lieved  it  could  be  adopted  by  an  individual  engineer  or  small  group  within  a  matter  of  several 
weeks.  We  discovered  that  this  was  true  but  that  RMA  might  also  have  an  effect  upon  strategy 
as  well  as  upon  skills  and  procedures.  When  used  more  strategically — for  example,  as  part  of 
system  redesign — it  can  be  incorporated  (with  the  assistance  of  experts)  into  software  engi¬ 
neering  processes  over  a  period  of  several  months.  ® 

RMA  requirements  for  effective  application  are  limited.  For  example,  while  RMA  does  require 
engineers  to  reframe  their  understanding  of  scheduling  issues  to  a  more  abstract  level,^  mod¬ 
erate  training  and  help  with  initial  practical  application  is  required  for  people  to  be  effective  in 
using  the  technology.  RMA  can  be  adopted  by  an  individual  engineer  as  part  of  his  or  her  ap¬ 
proach  to  designing  or  analyzing  systems;  it  can  also  be  applied  at  almost  any  point  in  time  in 


®-  Software  technologies  often  require  not  only  changes  to  organizational  behavior  and  values,  as  in  the  case  of 
software  process  improvement  [a  variant  of  total  quality  management  (TQM)],  but  also  changes  to  existing  tech¬ 
nology,  as  in  the  introduction  of  computer-assisted  software  engineering  (CASE)  toois.  These  changes  typically 
occur  while  software  managers  and  developers  are  attempting  to  continue  business  as  usuai.  For  more  informa¬ 
tion,  see  Bouidin  [1989]  and  Grady  &  Caswell  [1987]. 

One  RMARTS  project  member  and  former  resident  affiliate  stated  in  an  interview  that  over  a  period  of  time,  his 
use  of  RMA  had  caused  a  shift  in  his  view  of  architectures.  He  began  to  see  an  important  distinction  between 
“architectures”  and  “attributes  of  architectures.”  He  noted  that  he  began  to  look  at  “software  performance  in  terms 
of  preemption,  computation,  and  blocking.”  (These  are  concepts  used  in  RMA  theory.) 
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system  development  or  maintenance.  RMARTS  Project  members  recount  how  they  are  able 
to  quickly  demonstrate,  in  consuiting  and  classroom  settings,  the  utiiity  of  the  approach.  In  this 
respect,  we  classify  RMA  as  of  relatively  “small”  size,  at  least  in  terms  of  usual  application. 

2.1.2  Observability 

These  same  factors  make  RMA  transition  readily  “observable”  [Rogers,1983]  within  a  reason¬ 
able  period  of  time.  RMA  can  be  adopted  incrementally:  its  adoption  can  range  from  informal 
application  to  an  existing  system  by  one  engineer  to  application  across  an  entire  division  as 
standard  practice  in  designing  new  systems.  In  addition,  because  RMA  is  a  technology  without 
extensive  “cultural”  content  (in  contrast  with  a  technoiogy  such  as  total  quality  management), 
we  beiieve  its  transition  process  is  less  muddied  by  major  shifts  in  attitude  and  belief  systems.® 

The  size  of  the  technology  and  its  obervability  are  directly  related  to  the  design  of  the  case 
study  and  the  determined  unit  of  analysis.  See  Section  4.1 .2,  Materials  and  Procedure,  for  fur¬ 
ther  discussion  of  these  issues. 

2.1.3  Maturity 

Finally,  the  maturity  of  RMA  is  important.  Given  the  process-intensive  nature  of  software  tech¬ 
nologies  [Tornatzky  &  Fleischer,  1990],  less  mature  technologies  are  likeiy  to  have  poorly  de¬ 
fined  and  unstabie  transition  processes.  The  limited  impact  of  RMA  on  the  structure  and  work 
processes  of  the  organization  makes  it  somewhat  easier  to  separate  technicai  probiems  from 
problems  in  the  transition  approach.  In  fact,  while  RMA  is  not  yet  fuliy  mature  in  the  sense  of 
a  commercial  whole  product  [Moore,  1 991  ],  RMA  as  an  analytical  method  is  no  ionger  evolving 
rapidly.® 

In  addition  to  these  implementation  characteristics,  we  chose  RMA  because  the  technology 
was  being  developed  at  the  SEI.  This  gave  us  ready  access  to  subject  matter  experts  and  to 
their  contacts,  including  the  change  agent  at  ComCo,  Woodville,  who  eventually  arranged  for 
our  interviews.  Our  technical  informant,  a  former  ComCo  empioyee,  added  invaluable  com¬ 
mentary  on  the  interaction  of  ComCo  culture  and  RMA  technology. 


Any  technology  has  some  cultural  content,  in  the  sense  of  requiring  an  adjustment  in  the  user’s  belief  system  and 
behavior.  For  example,  RMA  requires  acceptance  of  logical  concurrency,  a  shift  for  most  software  engineers  and 
their  managers,  with  some  implications,  albeit  limited,  for  the  structure  and  scheduling  of  their  work.  It  does  not, 
apparently,  require  restructuring  of  the  process  of  software  project  management  or  of  reward  systems. 

We  believe  this  is  why  software  tools  that  encapsulate  and  guide  the  use  of  the  RMA  method  are  now  emerging. 
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3  Related  Research 


Research  on  technology  adoption  and  implementation  is  best  understood  in  a  larger  context, 
since  the  literature  is  not  specific  to  one  field.  Rather,  adoption  and  implementation  are  often 
associated  with  other  topics,  including  technology  assessment,  technology  transfer,  business, 
and  policy  and  management.  The  diffusion  research  tradition  is  also  the  property  of  many  dis¬ 
ciplines  ranging  from  communication,  education,  marketing,  information  technology,  anthro¬ 
pology,  public  health,  rural  sociology,  and  others  [Rogers,  1983;  Tornatzky  et  al,  1983]. 

Thus,  adoption  and  implementation  can  be  considered  in  terms  of  related  topics  and  how  var¬ 
ious  disciplines  instantiate  the  diffusion  of  innovations,  and  also  in  terms  of  the  genre  of  the 
inquiry  (e.g.,  framework  or  reference  model,  case  study,  experience  report).  The  scope  of  this 
technical  report  precludes  a  full  literature  review  or  bibliographic  survey:  rather,  we  suggest 
that  related  research  on  adoption  and  implementation  can  be  usefully  framed  by  the  concep¬ 
tual  model  below,  on  technology  maturation  (Figure  3-1).^° 


R&D 


New  Product  Adoption  & 

Development  Implementation 


Figure  3-1:  Technology  Life  Cycle 

Technology  transition  occurs  throughout  technology  development  from  the  birth  of  a  technol¬ 
ogy  until  its  retirement.  Technology  that  has  been  commercially  developed  and  is  in  use  in  an 
organization  has  most  likely  been  transitioned  at  least  twice,  between  communities  respective- 

The  technology  maturation  life  cycle  represents  one  part  of  a  larger  framework  for  software  technology  transition. 
For  additional  information,  see:  A  Conceptual  Framework  for  Software  Technology  Transition  by  P.  Fowler  and 
L.  Levine,  1993,  (CMU/SEI-93-TR-31 )  Pittsburgh:  Software  Engineering  Institute,  Carnegie  Mellon  University. 
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ly  concerned  with  research  and  development  (R&D),  new  product  development,  and  adoption 
and  implementation.  In  addition,  the  technology  is  transitioned  as  it  progresses  through  its  life 
cycle  within  each  of  these  communities  or  businesses.  The  composite  model  represented  here 
is  composed  of  three  interlocking  life  cycles. 

In  the  following  discussion,  we  concentrate  on  the  literature  that  is  specific  to  the  processes  of 
adoption  and  implementation.^^  This  literature  is  then  classified  according  to  conceptual  or 
theoretical  models,  case  studies,  and  experience  reports.  We  begin  with  conceptual  models 
and  meta-analyses,  where  we  also  address  high-level  studies  of  diffusion  and  transfer. 

3.1  Conceptual  Models  and  Meta-Analyses 

Rogers’  [1983]  classic  Diffusion  of  Innovations  offers  a  useful  point  of  departure.  He  defines 
implementation  as  follows: 

Implementation  occurs  when  an  individual  (or  other  decision-making  unit) 
puts  an  innovation  to  use.  Until  the  implementation  stage,  the  innovation- 
decision  process  has  been  strictly  a  mental  exercise.  But  implementation 
involves  overt  behavior  change,  as  the  new  idea  is  actually  put  into  practice. 


He  asks. 

When  does  the  implementation  stage  end?  It  may  continue  for  a  lengthy 
period  of  time,  depending  on  the  nature  of  the  innovation.  But  eventually  a 
point  is  reached  at  which  the  idea  becomes  an  institutionalized  and 
regularized  part  of  the  adopters’  ongoing  operations.  The  innovation  finally 
loses  its  distinctive  quality  as  the  separate  identity  of  the  new  idea  disappears 
(pp.  174-175;  italics  Rogers). 

Rogers  is  well  recognized  for  his  history  of  the  diffusion  tradition  and  specific  treatments  of 
adopter  categories,  the  innovation  decision  process,  and  the  attributes  of  innovations.  His 
adopter  population  scheme  analyzes  the  characteristics  and  preferences  of  innovators,  early 
adopters,  early  and  late  majority  segments,  etc.  Innovation-decision  is  that  “process  through 
which  an  individual  (or  other  decision-making  unit)  passes  from  first  knowledge  of  an  innova¬ 
tion,  to  decision  to  adopt  or  reject,  to  implementation  of  the  new  idea,  and  to  confirmation  of 
this  decision”  (p.  165).  This  model  includes  the  stages  of  knowledge,  persuasion,  decision,  im¬ 
plementation,  and  confirmation.  Many  of  these  concepts,  including  Roger’s  notion  of  the  at¬ 
tributes  of  innovations,  are  not  without  limitations  or  critique;  however,  Rogers  remains  the 
most  influential  theorist  in  the  diffusion  tradition. 

Tornatzky  &  Klein’s  [1982]  meta-analysis  is  primarily  concerned  with  methodological  issues  in 
the  study  of  innovation  as  reflected  in  the  set  of  75  studies  they  examine.  Their  list  of  “ideal 


1 1  •  Adoption  and  implementation,  or  the  introduction  of  a  mature  technology  that  is  new  to  an  organization,  typically 
includes  the  following  phases:  needs  assessment;  selection  of  candidate  products;  evaluation  of  candidate  prod¬ 
ucts;  introduction  of  seiected  product  to  management  and  to  end  users  (including  pilot  use);  gathering  of  feedback 
from  management  and  users;  implementation  planning;  implementation;  product  maintenance;  and  end  user  sup¬ 
port  [Fowler  &  Levine,  1 993;  Bouldin,  1 989].  For  descriptions  of  the  phases  associated  with  the  R&D  and  the  new 
product  development  life  cycles,  see  Fowler  &  Levine,  1993. 
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innovation  attribute  studies”  discusses  principles  in  innovation  research.  In  particular,  they 
note  that  both  adoption  (which  they  define  as  a  “yes/no”  decision)  and  implementation  must 
be  treated  as  dependent  variables.  They  suggest  “...only  measures  of  degree  of  implementa¬ 
tion  begin  to  capture  the  variability  of  post-adoption  behavior”  (p.  40).  Tornatzky  &  Klein  also 
assert  that  multiple  innovation  characteristics  should  be  examined  and  that  organizations  as 
adopting  agents  should  be  studied  as  well  as  individual  adopters. 

Like  Tornatzky  &  Klein,  Downs  &  Mohr  [1976]  stress  the  need  to  study  degree  of  implementa¬ 
tion,  noting  that  “...operationalizing  innovation  by  the  extent  of  implementation  comes  closer 
to  capturing  the  variations  in  behavior  that  we  really  want  to  explain”  (p.  709).  Downs  &  Mohr 
point  to  a  lack  of  coherence  in  diffusion  research:  “perhaps  the  most  alarming  characteristic  of 
the  body  of  empirical  study  of  innovation  is  the  extreme  variance  among  its  findings”  (p.  700). 
They  propose  that  “the  most  straightforward  way  of  accounting  for  this  empirical  instability  and 
theoretical  confusion  [in  research  on  innovation]  is  to  reject  the  notion  that  a  unitary  theory  of 
innovation  exists  and  postulate  the  existence  of  distinct  types  of  innovations  whose  adoption 
can  best  be  explained  by  a  number  of  correspondingly  distinct  theories”  (p.  701).  Downs  & 
Mohr,  then,  go  on  to  define  primary  sources  of  instability:  (1)  variation  among  primary  at¬ 
tributes,  (2)  interaction,  (3)  ecological  inferences,  and  (4)  varying  operationalizations  of  inno¬ 
vation. 

Damanpour’s  [1991]  meta  analysis  is  concerned  with  examining  innovativeness  in  organiza¬ 
tions  more  generally.  The  study  contains  a  brief  but  useful  discussion  of  the  literature  describ¬ 
ing  organizational  characteristics  that  support  implementation.  He  holds  that  “organizations 
with  diverse  and  differentiated  task  structures  initiate  more  innovations,  and  those  with  formal¬ 
ized  and  centralized  structures  implement  more  innovations”  (p.  562).  Damanpour  also  pro¬ 
vides  a  set  of  “organizational  determinants” — ^for  example,  technical  knowledge  resources, 
managerial  tenure,  and  slack  resources — ^with  definitions  and  references.  (For  a  discussion  of 
the  role  of  resources  in  the  acquisition  and  implementation  of  RMA,  see  Section  5.3.3.)  Dam¬ 
anpour  [1991]  and  Nord  &  T ucker  [1 987]  note  that  organizations  may  typically  adopt  more  than 
one  innovation  at  a  time.  Tyre  &  Orlikowski  [1993]  argue  that  technological  improvement  is 
rarely  steady  and  uninterrupted;  rather,  the  process  alternates  between  periods  of  intensive 
change  and  routine  use.  Their  data  show  that  “adaptation  to  new  technologies  often  occurs  in 
a  ‘lumpy’  or  episodic  pattern”  (p.13). 

Tornatzky  et  al  [1983]  offer  an  early  reference  volume  on  innovation-process  research.  Their 
approach  emphasizes  organizational  context,  observing  that  many  other  texts  are  discipline- 
or  technology-focused.  In  addition,  the  “key  point  which  differentiates  diffusion  research  from, 
say,  innovativeness  research  or  other  innovation  process  models  is  that  diffusion  takes  as  its 
starting  point  the  innovation  rather  than  the  organizatiorf  (p.  78;  italics  Tornatzky  et  al).  These 
authors  cover  concepts,  analytical  themes,  events  from  technology  generation  through  imple¬ 
mentation  and  dissemination,  and  strategies  for  managing  innovation.  Of  special  interest  is  the 
discussion  of  the  user’s  role  in  implementation,  including  the  place  of  adaptation,  modification, 
and  reinvention.  Also  unusual  is  the  closing  treatment  on  government  policy  and  innovation. 
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Tornatzky  &  Fleischer  [1990]  provide  a  section  on  the  adoption  and  implementation  of  tech¬ 
nology,  and  a  chapter  on  implementation.  The  iatter  discusses  the  literature  and  attempts  to 
integrate  and  synthesize  an  approach  that  may  be  likely  to  succeed.  They  present  four  per¬ 
spectives  on  impiementation:  technocentric,  sociocentric,  confiict/bargaining,  and  systems  de¬ 
sign.  The  first  focuses  on  technical  detail  at  the  expense  of  social  context;  the  second  focuses 
on  social  detail  at  the  expense  of  technical  issues;  and  the  third  concentrates  on  political  rela¬ 
tionships  and  power.  The  fourth,  systems  design,  draws  from  the  first  three,  emphasizing  “de¬ 
signing”  the  technological  system  to  meet  the  requirements  of  the  situation,  to  integrate  the 
system  with  the  larger  technical  system,  and  to  maintain  the  system.  In  addition,  Tornatzky  & 
Fleischer’s  emphasis  on  maintenance  is  atypical:  it  is  as  much  an  error  to  ignore  maintenance 
issues  in  implementation  as  it  has  been  to  ignore  implementation  issues  in  adoption. 

Several  books  are  noteworthy  for  their  exploration  of  the  relationships  between  organizations 
and  innovation.  Kanter  [1993]  is  attuned  to  modern  management’s  need  to  empioy  mecha¬ 
nisms  to  foster  and  facilitate  innovation  in  the  corporation.  She  suggests  the  concept  of  the 
“parallel  participative  organization”  as  an  innovation  and  change  tool.  Kanter  maintains  that  “it 
is  possibie  for  a  ‘mechanistic’  production  hierarchy  and  an  ‘organic’  participative  organization 
to  exist  side  by  side,  carrying  out  different  but  complementary  kinds  of  tasks.  These  two  orga¬ 
nization  types  are  not  necessarily  opposites,  but  different  mechanisms  for  involving  people  in 
organizational  tasks”  (p.  204). 

Morgan  [1 986]  offers  a  comprehensive  description  of  organizations  as  machines,  organisms, 
brains,  cultures,  political  forums,  etc.  Like  Tornatzky  &  Fleischer,  he  attends  to  interacting  or- 
ganizationai  subsystems.  In  his  view,  technical  change  cannot  occur  independently  of  change 
in  operations,  business  strategy,  structure,  and  culture. 

Allen  [1986]  focuses  on  the  communication  system  in  managing  the  flow  of  technology.  He 
provides  particular  insight  into  communication  among  scientists  and  engineers,  especially  as 
he  considers  the  gatekeeping  function  within  a  technical  organization.  A  gatekeeper,  filtering 
information  he  or  she  gathers  from  external  sources,  can  leverage  or  block  vital  technology. 

3.2  Case  Studies 

Nord  &  Tucker  [1987]  examine  the  implementation  of  NOW  (interest-bearing  checking)  ac¬ 
counts  in  banks  and  savings  and  loan  associations.  These  accounts  are  more  organizational 
than  technical  innovations;  however,  they  are  also  “process”  innovations  affecting  differing  lev¬ 
els  and  types  of  personnel. 

Nord  &  Tucker  offer  a  historical  perspective  on  implementation  in  organizationai  contexts  and 
remark  on  the  lack  of  a  theoretical  basis  for  study.  They  discuss  a  conceptuai  framework  de¬ 
veloped  in  conjunction  with  their  research.  The  framework  includes:  definitions  of  innovation 
and  implementation,  effects  of  innovation  design  on  implementation  (including  the  relativity  of 
the  concepts  of  routine  and  radical),  effects  of  organization  on  implementation,  and  interper¬ 
sonal  processes  in  implementation.  Organizational  effects  involve  the  impact  of  organization 
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structure  (e.g.,  mechanistic  or  organic)  on  innovation,  temporary  structures  that  facilitate  im¬ 
plementation,  centralization  and  formalization,  history,  size,  culture,  organizational  learning, 
and  interaction  with  environment. 

Leonard-Barton  [1988a:1988b;1990]  studies  the  implementation  of  software  innovations  from 
within  the  innovation  research  tradition.  Especially  relevant  is  her  treatment  of  reinvention  in 
her  work  on  mutual  adaptation  [1988a].  She  contends  that  “initial  implementation  of  a  new 
technology  is  an  extension  of  the  invention  process.  That  is,  instead  of  the  predictable  realiza¬ 
tion  of  a  preprogrammed  plan,  implementation  is  a  dynamic  process  of  mutual  adaptation  be¬ 
tween  the  technology  and  its  environmenf  (p.  252).  She  describes  that  adaptation  is 
necessary  in  response  to  three  kinds  of  misalignment  between  the  technology  and  (1)  techni¬ 
cal  requirements,  (2)  the  system  through  which  the  technology  is  delivered  to  users,  and  (3) 
user  organization  performance  criteria.  She  also  discusses  small-cycle  adaptations  and  large- 
cycle  adaptations,  where  the  former  require  a  relatively  minor  adjustment  such  as  a  new  soft¬ 
ware  module,  and  the  latter  may  send  the  designers  back  to  square  one.  Leonard-Barton  elab¬ 
orates  on  notions  of  degree  of  implementation  [Leonard-Barton,  1 988a;  Tornatzky  &  Fleischer, 
1990]. 

In  a  similar  vein,  Leonard-Barton  [1988b]  asserts  that  implementation  can  be  managed  well  or 
not,  depending  upon  how  carefully  factors  such  as  implementation  characteristics  and  organi¬ 
zational  characteristics  are  taken  into  account.  Implementation  characteristics  include  trans¬ 
ferability  (preparedness  and  communicability),  implementation  complexity  (organizational 
span  and  organizational  scope),  and  divisibility  (modularization,  individualization).  Although 
these  characteristics  “do  not  directly  determine  success  or  failure  of  implementation,  they  cre¬ 
ate  conditions  that  must  be  skillfully  managed  to  achieve  success”  (p.  627).  Also,  on  the  topic 
of  degree  of  implementation,  Zmud  &  Apple  [1992]  assert  that  there  are  two  components  of 
incorporation:  routinization,  which  they  claim  has  been  the  subject  of  prior  studies,  and  infu¬ 
sion:  “the  extent  to  which  the  full  potential  of  the  innovation  has  been  embedded  within  an  or¬ 
ganization’s  operational  or  managerial  work  systems”  (p.148).  In  their  case  study  of  the  use  of 
supermarket  scanner  technology,  the  authors  explore  the  relationship  between  routinization 
and  infusion,  and  suggest  measures  for  both. 

Orlikowski  [1993]  studied  two  organizations’  experiences  with  the  adoption  and  use  of  CASE 
tools  over  time.  She  pays  specific  attention  to  how  organizations  experience  incremental  and 
radical  change,  and  she  builds  a  framework  to  represent  these  organizational  issues  in  tool 
adoption.  Of  critical  importance  in  understanding  both  experiences  were  the  change  process, 
organizational  context,  and  intentions  and  actions  of  key  players  associated  with  adoption  and 
use.  Orlikowski  observes:  “where  IS  [information  systems]  managers  introduce  CASE  tools  to 
improve  the  existing  process  of  systems  development  through  increasing  productivity  or  cut¬ 
ting  costs,  organizations  will  likely  experience  process  variations.  Where  the  CASE  tools  are 
used  to  improve  the  product  delivered  to  clients,  without  significantly  altering  its  nature,  own¬ 
ership,  or  delivery  arrangements,  organizations  will  likely  experience  product  variation^’  (p. 
331;  italics  Orlikowski).  She  then  goes  on  to  make  similar  distinctions  between  process  and 
product  reorientation  in  the  case  of  radical  change  processes. 
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Leonard-Barton  [1990]  is  also  closely  focused  on  intraorganizational  themes.  She  distinguish¬ 
es  between  types  of  transfer  situations,  drawing  evidence  gathered  from  over  fifty  cases  relat¬ 
ed  to  the  use  of  productivity-  or  production-enhancing  tools.  Employing  her  earlier  distinction 
between  innovation  span  (number  of  users)  and  innovation  scope  (number  of  applications), 
she  represents  four  modes:  simple,  complex,  point-to-point,  and  diffusion.  “The  fewer  the 
user/receivers  per  technology  application,  the  closer  the  situation  is  to  a  pure  point-to-point 
transfer,  the  theoretical  extreme  of  which  wouid  be  the  diffusion  of  a  custom  made  tool  for  one 
user.  At  the  other  extreme  would  be  diffusion  of  a  generic  tool  to  thousands  of  users”  (p.  46). 
Leonard-Barton  suggests  that  researchers’  disciplinary  backgrounds  have  shaped  their  con¬ 
cern  with  either  point-to-point  or  diffusion,  arguing  there  is  much  for  practitioners  and  academ¬ 
ics  to  gain  by  understanding  the  differences  and  commonalities  of  these  modes. 

Souder,  Nashar,  &  Padmanabhan’s  [1990]  discussion  of  best  technology  transfer  practices 
derives  from  examining  forty  successful  technology  transfer  programs  at  twenty  organizations. 
Thirty-seven  practices  were  identified  and  categorized  according  to  how  important  they  were 
in  four  different  stages  of  technology  transfer:  prospecting,  developing,  trial,  and  adoption. 
“Adoption  implies  strong  emotional  and  financial  commitments  to  routine  use”  (p.  5).  While  oth¬ 
er  researchers  refer  to  such  characteristics,  Souder  goes  further  by  ranking  them  from  “option¬ 
al”  to  “essential”  and  by  statistically  determining  relationships  among  the  seven  types  of 
practices:  analytical,  facilities,  pro-actions,  people-roles,  conditions,  technology  quality,  and 
organization.  The  seven  types  of  best  practices  were  found  to  “interrelate  in  cause-effect 
chains.”  Souder  argues  that  “collectively,  these  results  were  shown  to  comprise  a  benchmark 
model  that  managers  can  consult  to  assist  them  in  developing  more  effective  technology- 
transfer  strategies”  (p.13), 

3.3  Experience  Reports 

From  the  literature  on  software  engineering  and  information  technology,  there  is  a  set  of  ma¬ 
terials  best  categorized  as  experience  reports.  Generally,  the  authors  are  not  familiar  with  in¬ 
novation  literature  but  have  considerable  practical  experience  which  they  describe  and  from 
which  they  extrapolate  prescriptive  advice.  Bouldin’s  [1989]  book  Agents  of  Change:  Manag¬ 
ing  the  Introduction  of  Automated  Tools  is  essentially  a  guidebook  on  implementing  computer 
assisted  software  engineering  (CASE)  tools  across  a  large  organization.  It  is  based  on  Boul¬ 
din’s  experience  as  a  software  manager  with  those  responsibilities.  Grady  &  Caswell’s  [1987] 
Software  Metrics:  Establishing  a  Company-Wide  Program  is  a  similar  treatment  based  on  their 
experience  at  Hewlett  Packard.  Ackerman,  Fowler  &  Ebenau  [1983]  have  written  about  imple¬ 
menting  software  inspections  in  large  software  organizations.  Two  more  broadly  targeted 
treatments  are  Pressman’s  [1 988],  addressing  the  implementation  of  a  set  of  software  prac¬ 
tices  and  technologies  in  support  of  software  engineering,  and  Eason’s  [1988],  on  implement¬ 
ing  information  technology  systems  within  end-user  organizations.  Strauss  &  Ebenau  [1994] 
describe  implementation  strategies  and  guidance  for  the  adoption  of  formal  software  inspec¬ 
tions. 
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Together,  such  reports  offer  a  robust  composite  of  implementation  issues  particuiar  to  soft¬ 
ware  organizations.  While  these  lessons  are  not  derived  by  means  of  empiricai  research,  they 
refiect  the  perceptions  of  a  number  of  software  practitioners  with  extensive  experience.  Key 
concerns  inciude  forms  of  resistance  and  conjecture  regarding  its  origin,  management  issues 
regarding  cost  and  time  to  implement,  and  attitude  toward  the  implementation  of  different  soft¬ 
ware  technoiogy  types. 
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4 


Method 


4.1  Design 

In  empirical  research,  it  is  conventional  to  talk  about  triangulation  and  to  design  studies  that 
use  converging  methods  and  measures  to  investigate  a  question  or  hypothesis.  Triangulating 
is  one  way  to  insure  reliable  data  collection  and  reduce  threats  of  invalidity.  The  concept  is  par¬ 
ticularly  suggestive  for  research  on  technology  transition.  A  complete  understanding  of  tech¬ 
nology  transition  requires  that  one  pay  attention  to  multiple  units  of  analysis,  including  the 
technical,  institutional,  and  cultural  grounds  for  the  adoption  and  implementation  of  innova¬ 
tions.  For  this  reason,  the  case  study  of  the  transition  of  RMA  was  conceived  of  in  two  parts. 
As  we  have  explained.  Part  1  was  concerned  with  the  analysis  of  transition  activities  according 
to  phases  of  a  technology  maturation  life  cycle.  Part  2  examines  the  adoption  and  implemen¬ 
tation  of  RMA  at  one  site  in  one  large  organization.  Together,  the  two  parts  offer  a  robust  pic¬ 
ture  of  the  transition  of  RMA,  allowing  us  to  attend  to  development  and  user  perspectives:  to 
technology  push  and  technology  pull.  The  more  technical  explanation  of  how  the  (two-part)  in¬ 
vestigation  of  RMA  can  be  seen  in  the  larger  context  of  case  study  design  follows. 

The  full  study  can  be  described  as  an  embedded  single  case  design  [Yin,  1984].  In  simple 
terms,  the  case  study  is  about  the  transition  of  RMA,  and  the  study  involves  several  levels  of 
analysis.  The  main  unit  was  the  technology  transition  effort  as  a  whole;  the  two  smaller  sub¬ 
units  were  (Part  1 )  RMARTS  Project  transition  activities  and  (Part  2)  a  subset  of  adopters’  and 
users’  perspectives  on  the  technology.  For  Part  1  of  the  investigation,  a  combination  of  data 
collection  techniques  was  used,  ranging  from  analysis  of  historical  documents  (including 
plans,  reports,  and  statements)  to  informal  data  collection  through  the  researchers’  atten¬ 
dance  at  RMARTS  meetings  and  interviews  conducted  with  RMARTS  staff.  The  data  collec¬ 
tion  for  Part  2  included  interviews  with  10  members  at  one  site  in  one  large  multinational 
organization,  henceforward  referred  to  as  ComCo,  Woodville.  The  following  subsections.  Sub¬ 
jects  (4.1.1)  and  Materials  and  Procedure  (4.1 .2),  outline  these  aspects  of  the  investigation, 
including  the  interview  schedule  and  the  procedure  for  reviewing  the  findings. 

This  case  study  on  the  transition  of  RMA  is  best  described  as  enlightening  with  respect  to  our 
ability  to  observe  and  analyze  a  situation  not  previously  accessible  to  scientific  investigation. 
In  this  context,  “the  case  is  therefore  worth  conducting  because  the  descriptive  information 
alone  will  be  revelatory”  [Yin,  1984,  p.  43].  To  date,  the  transition  of  RMA  technology  has  not 
been  the  subject  of  research.^ ^  Nor  have  software  developer  perspectives  on  transition  activ¬ 
ities  and  user  perspectives  on  adoption  and  implementation  been  juxtaposed  in  one  case 
study.  In  this  regard,  we  break  new  ground. 

As  is  common  with  single  (embedded  and  holistic)  case  studies,  we  cannot  extend  our  obser¬ 
vations  about  RMA  to  other  technologies  and  other  technical  projects.  Emerging  theory  about 

For  a  recent  experience  report,  see:  S.J.  Ignace,  R.L.  Sedimeyer,  &  D.J.  Thuente  [1994].  Integrating  rate-mono- 

tonic  analysis  into  real-time  software  deveiopment.  In  L.  Levine  (Ed.),  Diffusion,  Transfer  and  Implementation  of 

Information  Technology  (A-A5)  (pp.  257-274).  Amsterdam:  Eisevier  Science  B.V.  (North-Hoiiand). 
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software  technology  transition  must  be  tested  through  replication  of  the  findings  in  a  second 
or  third  technology  case,  where  the  theory  has  hypothesized  that  the  same  results  should  oc¬ 
cur.  Such  replication  logic  (attending  to  both  technology  and  organizational  context)  plays  a 
key  role  in  case  study  research  and  in  experimentation,  allowing  one  to  eventually  establish 
“external  validity”:  the  ability  to  generalize  beyond  the  specific  instance  [Yin,  1984;  Chadwick, 
Bahr  &  Albrecht,  1984]. 

4.1.1  Subjects 

The  data  used  for  the  RMA  case  study  and  on  which  this  report  is  based  were  derived  from 
interviews  with  10  members  of  one  large  organization.  These  individuals  were  affiliated  with  2 
departments,  3  projects,  and  one  advanced  technical  solutions  group,  and  all  of  these  individ¬ 
uals  had  some  knowledge  of,  and  experience  with,  the  use  of  RMA  technology.  Included  in  the 
subjects  is  the  change  agent  (DV)  who  served  as  our  host,  and  whom  we  interviewed  one 
month  earlier. 

Of  thelO  interviewees,  3  were  managers,  6  were  technical  staff,  and  one  was  a  distinguished 
fellow  of  the  organization.  Nine  had  a  minimum  of  9  years  of  experience  and  had  spent  their 
entire  careers  at  this  organization,  and  3  had  more  than  20  years  of  experience.  One  person 
had  been  an  employee  for  only  3  months;  however,  he  had  10  years  of  experience  at  another 
similar  organization.  All  but  one  of  these  individuals  were  considered  senior  personnel;  that  is, 
they  were  accomplished  software  developers,  with  extensive  knowledge  of  the  application  do¬ 
mains  in  which  they  worked. 

We  interviewed  the  subjects  about  their  experience  with  RMA.  All  of  the  projects  that  the  in¬ 
terviewees  discussed  concerned  software  for  real-time  embedded  systems,  but  the  projects 
varied  in  nature.  The  technical  people  described  their  experiences  with  RMA  primarily  on  four 
specific  software  projects  that  included 

•  A  system  supporting  artificial  Intelligence  (Al)  applications. 

•  An  avionics  system  upgrade. 

•  A  flight  simulator. 

•  An  optical  character  recognition  (OCR)  system. 

The  two  software  development  managers  described  experience  with  RMA  in  more  general 
terms.  The  manager  of  the  advanced  technical  solutions  group  described  how  her  group  intro¬ 
duced  RMA  across  Woodville  and  how  she  supported  her  staff  (including  the  change  agent) 
in  their  work. 

4.1.2  Materials  and  Procedure 

In  March  1 993,  the  first  interview  was  conducted  with  (whom  we  call)  DV,  the  primary  change 
agent  for  RMA.  At  that  time,  DV  described  his  experiences  helping  software  projects  (across 
the  site)  to  apply  the  technology.  At  the  preliminary  meeting  and  at  subsequent  interviews,  the 
researchers  were  accompanied  by  a  technical  informant  (an  SEI  employee)  who  was  formerly 
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a  senior  engineer  at  ComCo.^^  The  informant  was  enlisted  to  help  us  with  clarification  of  find¬ 
ings  from  a  technical  perspective,  as  well  as  with  information  about  the  management  process¬ 
es  and  the  culture  of  the  organization. 

The  preliminary  meeting,  which  lasted  about  one  hour,  was  held  to  confirm  ComCo’s  willing¬ 
ness  to  participate  in  the  interview  study.  After  the  meeting,  we  reconsidered  assumptions 
about  ComCo,  Woodville’s  adoption  process  and  the  appropriate  unit  of  analysis  for  study.  For 
example,  we  had  anticipated  a  classic  diffusion  process,  where  DV  facilitated  the  introduction 
of  RMA  within  each  project,  at  a  specific  time,  by  working  with  and  educating  members  of  the 
project’s  technical  staff  in  the  use  of  RMA.  The  change  agent  explained  that  this  was  not  the 
case,  and  that  for  each  project,  one  or  two  senior  personnel  had  applied  RMA  somewhat  dif¬ 
ferently  and  as  they  perceived  the  need.  We  came  to  see  that  the  nature  of  the  technology  in 
combination  with  its  product  immaturity  meant  that  site-level  support  was  required  for  project- 
level  use.^"^  On  that  basis,  we  reasoned  that  the  appropriate  unit  of  analysis  was  not  the 
project’s  adoption  but  rather  the  individual’s  experience  with  RMA.  Thus,  as  a  result  of  the  pre¬ 
liminary  meeting,  we  requested  that  subsequent  interviews  be  with  individuals  who  were  re¬ 
sponsible  for  applying  RMA  in  one  or  more  projects.  One  month  later,  in  April  1 993,  we  visited 
the  organization,  once  again  accompanied  by  our  technical  informant. 

In  addition  to  collecting  basic  demographic  information,  such  as  job  title,  job  description,  and 
number  of  years  in  the  organization,  the  interview  schedule  consisted  of  1 4  open-ended  ques¬ 
tions  (see  Appendix).  We  were  particularly  interested  in  how  the  subjects  became  aware  of 
RMA,  when  they  realized  RMA  was  relevant  to  their  work,  and  when  they  decided  to  use  RMA. 
We  were  also  interested  in  issues  surrounding  ease  of  use,  observability,  trial  use,  and  roles 
played  by  interviewees  in  the  adoption  process.  Subjects  were  encouraged  to  provide  addi¬ 
tional  information  that  they  thought  was  pertinent  and  to  respond  to,  or  deviate  from,  the  inter¬ 
view  questions  as  they  saw  fit.  In  this  respect  the  interview  schedule  was  used  as  a  guide  to 
ensure  that  certain  issues  we  saw  as  relevant  were  raised  or  identified. 

We  met  with  some  subjects  individually  and  with  others,  when  they  were  from  the  same 
project,  in  a  small  group.  A  total  of  seven  interviews  were  conducted  on  one  day,  with  each 
interview  lasting  approximately  one  hour.  The  procedure  was  as  follows:  initially,  we  intro¬ 
duced  ourselves  to  the  interviewee/s.  We  explained  that  we  were  completing  a  two-part  case 
study  on  RMA  and  that  our  goal  was  to  understand  their  experiences  with  the  introduction  and 
use  of  RMA  at  their  organization.  We  noted  that  this  was  part  of  a  iarger  effort  to  understand 
the  processes  of  adoption  and  implementation  of  software  technologies  in  organizationai  set¬ 
tings.  In  addition,  we  indicated  that  we  were  interested  in  improving  transition  success  for  soft¬ 
ware  technologies. 

In  addition,  in  Part  1  of  the  case  study,  we  conducted  roughly  five  hours  of  interviews,  over  three  sessions,  with 
our  technical  Informant.  He  provided  considerable  background  on  earlier  events  related  to  RMA  at  ComCo. 

Early  on,  we  anticipated  being  able  to  observe  a  full  cycle  of  adoption  within  at  least  one  project  and  perhaps 
partial  cycles  within  a  few  others.  Subsequently,  we  considered  a  number  of  factors  that  related  to  why  it  was 
inappropriate  to  study  RMA  adoption  at  the  level  of  the  project.  These  factors  Included  the  size  of  some  projects, 
which  was  quite  large,  and  their  long  life;  the  range  of  application  for  RMA  so  that  the  technology  might  be  applied 
differently  over  time  and  over  long  intervals;  and  finally,  the  fact  that  packaged  products  and  services  did  not  exist 
for  the  purpose  of  introducing  RMA  to  the  projects  in  a  replicable  manner. 
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The  subjects  consented  to  participate  in  this  effort  given  the  following  conditions: 

1 .  Non-attribution  of  organization,  project,  or  individual. 

2.  Right  of  the  subjects  and  appropriate  other  personnel  to  review  reports  for 
accuracy  before  publication. 

3.  Willingness  to  be  available  to  answer  further  questions,  if  necessary. 

Because  we  were  studying  a  technology  that  SEI  people  had  worked  on  and  advocated,  we 
were  aware  that  subjects  might  have  a  tendency  to  tell  us  what  they  thought  we  wanted  to 
hear.  We  reminded  them  it  was  important  to  be  as  candid  and  critical  as  necessary  to  accu¬ 
rately  reflect  their  experience. 

4.1.3  Data  Analysis 

We  elected  not  to  audiotape  the  interviews  because  we  felt  that  doing  so  would  be  intrusive; 
instead,  the  three  of  us  took  extensive  notes  during  the  interviews.  We  attempted  to  record  as 
much  information  as  possible,  verbatim,  in  the  respondents’  own  words. 

Our  procedure  for  reviewing  the  interview  data  included  the  following: 

•  The  researchers  and  the  technical  informant  discussed  the  inten/iews 
immediately  following  and,  together,  documented  their  observations. 

•  The  researchers  completed  a  high-level  review  of  the  interview  data,  noting 
critical  issues  and  patterns. 

•  The  researchers  and  technical  informant  performed  a  close  reading  of  the 
data  to  corroborate  findings  and  clarify  discrepancies;  this  process  involved 
multiple  working  meetings  where  the  researchers  took  secondary  notes  on 
the  informant’s  comments. 

•  The  researchers  coded  the  data  according  to  seven  key  themes  (see  below). 

•  The  technical  informant  offered  necessary  elaborations  on  the  themes  and 
on  issues  related  to  the  technology  and  the  culture  of  the  organization;  these 
discussions  were  audiotaped  and  transcribed. 

In  the  data  analysis,  seven  themes  related  to  the  adoption  and  implementation  of  RMA 
emerged.  These  took  the  form  of  issues  clustered  under  the  following: 

1 .  Roles  and  key  players 

2.  Infrastructure 

3.  Innovative  culture 

4.  Innovation-decision  process 

5.  Technology  “use”  and  the  attributes  of  innovations 

6.  Codiffusion 

7.  The  concept  of  the  whole  product 
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There  were  two  parts  to  this  phase  of  coding.  Initially,  we  derived  the  themes  from  the  data; 
subsequently,  we  reviewed  the  data  to  determine  if  the  themes  or  clusters  failed  to  account  for 
other  critical  aspects  related  to  the  adoption  and  implementation  of  RMA  at  ComCo. 

In  the  following  Results  section  we  discuss  each  of  the  themes,  with  two  exceptions.  Because 
we  view  the  concept  of  the  whole  product  as  an  integrating  theme,  we  treat  it  in  the  Implica¬ 
tions  secWon.  Also,  we  discuss  the  theme  of  codiffusion  in  Implications,  where  we  consider  its 
relevance  for  developers  and  managers  of  third-generation  R&D. 
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5  Results 


When  we  first  contacted  ComCo,  Woodville,  we  were  interested  in  examining  the  adoption 
process  within  a  software  project  (typically  an  organizational  unit  of  a  few  to  several  dozen 
people,  all  working  together  to  develop  or  enhance  a  system  or  product).  We  had  assumed  we 
would  explore  how  RMA  technology  was  diffused  and  applied  at  that  level,  but  we  discovered 
that  this  was  possible  only  to  a  limited  extent.  The  interviewees  reflected  on  their  past  experi¬ 
ence  with  RMA:  on  previous  projects  and  on  the  preparation  of  proposals.  In  addition,  they  dis¬ 
cussed  their  current  experiences,  including  their  personal  assessments  of  RMA.  From  their 
comments,  it  was  clear  that  almost  all  had  depended  on  the  change  agent  (DV)  for  guidance 
in  the  initial  application  of  RMA  technology.  For  example,  one  of  the  managers  had  asked  the 
change  agent  to  brief  his  project  personnel  and  determine  if  RMA  was  suitable.  In  another 
case,  the  change  agent  had  approached  a  technical  person  to  try  to  arrange  a  pilot  use  of 
RMA,  for  which  there  was  special  funding.  In  all  cases,  the  change  agent  was  known  and  trust¬ 
ed  by  project  members,  and  played  a  significant  role  in  helping  them  to  begin  using  RMA.^® 
The  change  agent  was  a  site-level  resource,  loaned  to  projects  working  with  RMA. 

Once  we  discovered  that  the  adoption  and  implementation  process  was  not  self-contained  at 
the  level  of  the  project,  we  began  to  wonder  how  the  technology  had  actually  come  to  be  used. 
Application  of  RMA  had  occurred  at  the  project  level,  but  assistance  and  support  for  implemen¬ 
tation  had  come  from  the  site  level.  In  turn,  the  latter  observation  led  us  to  consider  the  nature 
of  the  relationship  between  site-level  support  and  the  concept  of  the  whole  product.  We  hy¬ 
pothesized  that  ComCo,  Woodville  was  successful  in  adopting  RMA  because  of  how  they  had 
compensated  for  the  lack  of  a  whole  product.  Evidence  for  this  grew  as  we  considered  a  num¬ 
ber  of  themes  that  emerged  out  of  the  data: 

•  The  roles  taken  by  key  players  in  the  adoption  of  RMA. 

•  An  infrastructure  within  ComCo,  Woodville  that  supported  software 
technology  adoption. 

•  ComCo’s  innovative  culture. 

•  The  attributes  of  RMA  as  an  innovation. 

•  The  codiffusion  of  RMA  with  the  Ada  programming  language. 

Each  of  these  themes  is  discussed  in  one  of  the  following  sections. 


Another  senior  technical  person,  DL,  with  a  corporate-ievel  assignment,  was  a  strong  champion.  He  provided, 
either  through  the  seminar  or  through  personal  contact,  information  on  RMA  to  five  of  the  interviewees.  The 
change  agent  provided  ongoing  technical  assistance  with  practical  application. 


CMU/SEI-93-TR-030 


23 


5.1  Roles:  Key  Players  in  RMA  Adoption 

A  number  of  people  played  key  roles  in  RMA  adoption  at  ComCo,  Woodville.  Most  of  the  indi¬ 
viduals  we  interviewed  were  change  participants;  in  addition,  we  spoke  with  the  change  agent 
(who  also  assumed  a  gatekeeper  role),  one  of  the  sponsors,  and  an  individual  who  can  be  de¬ 
scribed  as  an  innovator.''®  We  learned  about  other  individuals  who  were  involved  in  the  intro¬ 
duction  of  RMA  from  the  interviewees.  The  roles  we  identified  were  consistent  with 
descriptions  by  Rogers  [1983],  Conner  &  Patterson  [1982],  and  Fiman  [1989].  Table  1  identi¬ 
fies  these  roles  and  the  key  players  (referenced  by  initials  only)  who  assumed  these  roles  at 
ComCo. 


Table  1:  Roles  and  Key  Players 


Roles 

Key  Players 

Gatekeeper 

DL,  DV 

Champion 

DL 

Change  agent  /  Early  adopter 

DV 

Sponsor  (initiating) 

CK 

Sponsor  (sustaining) 

CK,  LH,  RB,  AMB 

Change  participant 

All 

Innovator 

PK 

The  gatekeeper  provides  access  to  information  from  outside  the  group  or  organization  of 
which  she  or  he  is  a  part  [Allen,  1977].  Five  of  the  interviewees  mentioned  the  champion  (DL), 
who  now  worked  largely  at  the  corporate  level,  as  being  responsible  for  their  initial  exposure 
to  RMA.^^  The  distinguished  senior  engineer  (PK)  had  the  earliest  contact  with  the  champion, 
sometime  in  1 982  or  1 983.  About  ten  years  ago,  he  told  us,  the  gatekeeper/champion  had  pro¬ 
vided  him  with  the  Liu  &  Layland  paper  [1973].^®  Senior  software  engineer  TK  remarked  that 
he  first  heard  of  RMA  from  the  gatekeeper/champion  in  1985-86  in  “an  academic-flavored  dis¬ 
cussion.”  In  1 986-87,  software  engineer  BH  had  contact  with  the  gatekeeper  during  a  trouble¬ 
shooting  activity.  The  manager  of  the  advanced  technical  solutions  group  (LH)  noted  that  the 
gatekeeper  “came  to  speak  with  them”  (to  her  and  her  group  of  software  developers).  Software 
engineer  JO  had  more  recently  had  contact  with  the  gatekeeper/champion,  at  a  conference 
tutorial  in  December  1 990. 

DV,  whom  we  characterize  below  as  the  primary  change  agent,  acted  in  part  as  a  gatekeeper. 
He  was  responsible  for  introducing  the  other  four  interviewees  to  RMA  during  1 987-1 990.  Two 

Rogers  [1983]  describes  five  categories  of  “adopter  populations.”  These  include  innovator,  early  adopter,  early 
majority,  late  majority,  and  laggard.  A  given  population  typically  follows  a  bell  curve  distribution. 

DL,  champion  and  gatekeeper,  was  operating  at  the  corporate  level  at  the  time  of  our  interviews,  and  so  he  was 
not  interviewed. 

Carnegie  Melion  University  faculty  evolved  the  original  [Liu  &  Layland,  1973]  rate  monotonic  scheduling  theory 
from  which  RMA  was  derived. 
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of  these  four  were  engineers,  and  information  on  RMA  was  provided  in  the  context  of  a  trial 
use  of  RMA  (1990-GP)  and  a  new  application  of  it  (1989-SN).  In  the  latter  case  the  engineer 
said  he  “relied  on  DV  to  get  him  started.”  The  remaining  two  interviewees  were  managers  and 
had  been  introduced  to  RMA  in  conjunction  with  a  proposal  (AMB)  for  a  time-critical  applica¬ 
tion,  and  also  in  conjunction  with  a  research  contract  (RB)  for  early  work  on  RMS. 

Gatekeeping^^  is  not  unusual,  according  to  Allen  [1977],  who  describes  the  function  as  fol¬ 
lows: 

There  will  always  be  some  people  who,  for  various  reasons,  tend  to  become 
more  acquainted  with  information  sources  outside  their  immediate  community. 

They  either  read  more  extensively  than  most  or  develop  personal  contacts  with 
outsiders.  A  large  proportion  of  these  people  in  turn  attract  colleagues  from 
within  the  community  who  turn  to  them  for  information  and  advice,  (p.  150). 


While  the  gatekeeper  typically  provides  general  information,  others  assume  roles  associated 
with  the  process  of  introducing  technological  change  and  the  tasks  involved  in  applying  a  new 
technology. 

The  champion  advocates  the  adoption  of  a  new  technology  and  proselytizes  on  its  behalf  at 
every  opportunity.  DL,  described  earlier  as  a  gatekeeper,  also  acted  as  a  champion.  Our  tech¬ 
nical  informant  told  us  that  DL  continues  to  act  as  champion  and  gatekeeper,  now  mainly  at 
the  corporate  level,  whereas  previously  he  had  done  so  at  the  level  of  the  site  as  well. 

The  change  agent  is  the  project  manager  of  the  change  effort — he  or  she  plans  the  tasks  in 
the  effort  and  then  leads,  tracks,  and  reports  on  the  effort  to  management  sponsors  and  par¬ 
ticipants.  The  change  agent  must  be  technically  expert  and  perceived  by  management  as 
highly  reliable.  The  change  agent  for  RMA  (DV)  was  an  experienced  engineer,  convinced  of 
the  importance  of  RMA,  and  adept  at  applying  the  technology  in  a  range  of  situations.  DV  had 
spent  his  entire  professional  career  at  ComCo  and  was  familiar  with  the  nature  of  technical 
work  and  contracts  executed  at  Woodville.  He  was  an  expert  in  real-time  systems  and,  at  the 
time  of  the  interviews,  was  assigned  to  the  advanced  technical  solutions  group.^°  In  addition, 
the  change  agent  was  active  in  an  external  professional  working  group,  which  exposed  him  to 
outside  perspectives  and  technical  information.  He  was  then  able  to  bring  these  perspectives 
back  and  share  information,  credibly,  at  Woodville.^^ 

The  change  agent  was  well  received  in  his  role — ^several  interviewees  commented  that  they 
had  first  had  contact  with  RMA  through  the  change  agent  or  had  worked  with  him  to  apply 
RMA.  Our  technical  informant  felt  that  the  number  and  organizational  level  of  the  interviewees 


Gatekeepers  are  often  opinion  leaders,  people  whose  advice  may  be  sought  with  respect  to  particular  technol¬ 
ogies. 

According  to  the  manager  of  the  advanced  technical  solutions  group  (LH),  their  job  was  “to  be  a  source  of  help 
in  resolving  development  problems.” 

This  supports  Rogers’  [1983]  concepts  of  homophily  and  heterophily,  where  the  successful  change  agent  is 
enough  like  the  constituency  she  or  he  works  with  to  have  credibility  with  them,  but  enough  unlike  them  to  be  a 
conveyor  of  information  from  outside  the  social  system. 
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who  made  themselves  readily  available  to  us  was  an  indication  of  their  respect  for  the  change 
agent. 

The  initiating  sponsor,  usually  a  highly  placed  executive,  sanctions  the  adoption  and  any  re¬ 
lated  changes  and  provides  strategic  leadership,  support  for  policy  changes,  and  resources. 
Without  a  sponsor,  technological  change  is  limited  to  whatever  can  be  accommodated  with  lit¬ 
tle  or  no  change  in  budget,  schedule,  etc.  Each  group  of  engineers  interviewed  mentioned  the 
importance  of  one  senior  manager  (CK)  at  Woodville,  who  was  responsible  for  all  software 
work  at  the  site.  He  was  identified  as  a  sponsor  for  RMA  when  it  was  included  in  one  project 
proposal;  here  he  acted  as  an  initiating  sponsor.  In  another  case,  CK  was  mentioned  as  one 
reason  why  Woodville  was  “ahead  of  the  state  of  the  art  in  software.”  In  addition  to  his  role  as 
initiating  sponsor,  CK  acted  as  a  sustaining  sponsor,  providing  ongoing  resources  and  lead¬ 
ership  for  software  technology  more  generally. 

The  manager  of  the  advanced  technical  solutions  group  (LH)  acted  as  a  sustaining  sponsor 
with  respect  to  RMA.  The  change  agent  (DV),  we  recall,  was  a  member  of  her  group.  LH  sup¬ 
ported  him  by  maintaining  the  group  (budget  and  credibility)  and  providing  an  organizational 
home.  She  also  offered  support  by  facilitating  lunchtime  seminars  and  planning  to  produce  a 
videotape.^^ 

Finally,  both  second-level  managers  (RB  and  AMB)  acted  as  sustaining  sponsors.  RB  man¬ 
aged  software  development  for  a  varied  group  of  programs  developing  real-time  systems  for 
defense  and  non-defense  government  applications,  including  optical  character  recognition 
(OCR).  He  supported  the  introduction  and  use  of  RMA  on  his  programs  because  he  saw  the 
value  of  new  technology  to  ComCo’s  competitive  position.  His  sponsorship  was  not  uncondi¬ 
tional,  however;  he  wanted  to  avoid  the  risks  that  might,  for  example,  come  from  retrofitting 
RMA  to  systems  built  largely  on  pre-existing  software.  He  admitted  that  this  “might  be  a  short¬ 
term  view.” 

AMB  oversaw  a  number  of  software  development  programs,  primarily  in  the  avionics  area,  and 
supported  the  application  for  RMA  in  design  as  well  as  system  evolution  work.  She  said  that 
for  one  program  her  department  is  working  on,  she  “doesn’t  think  they  have  an  alternative”  to 
using  RMA;  “the  program  is  so  complex,  they  can’t  afford  not  to  know  what’s  happening  in  the 
box.”  She  said  they  planned  to  use  RMA  through  each  phase  but  primarily  “up  front  to  lay  out 
architecture  and  tasking.”  AMB  was  the  sole  manager  who  mentioned  reading  “lessons 
learned”  papers.  She  also  read  research  papers  on  RMA. 

The  remaining  six  interviewees  were  participants  in  the  adoption  of  RMA.  Indeed,  anyone  af¬ 
fected  by  the  change  is  a  change  participant;  this  role  is  prerequisite  to  and  subsumes  all  the 
others.  All  but  one  of  these  people  were  attempting,  with  the  help  of  the  change  agent,  to  apply 
RMA  in  a  manner  consistent  with  the  intent  of  its  inventors.  The  exception,  the  distinguished 
senior  engineer  (PK),  held  a  position  in  which  his  job  was  to  “do  whatever  you  think  is  appro- 

The  advanced  technical  solutions  group  sponsored  a  series  of  lunchtime  seminars.  One  of  these  included  a  talk 
where  the  change  agent  (DV)  and  a  colleague  presented  information  about  RMA.  LH  was  considering  putting  this 
talk  on  video. 
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priate,”  and  he  was  working  on  an  experimental  system  applying  artificial  intelligence  technol¬ 
ogy.  He  had  adopted  RMA  very  early  (1982),  after  minimal  exposure — reading  a  research 
paper — and  with  no  assistance.  In  addition,  he  had  used  RMA  in  an  unanticipated  manner.^^ 
In  this  respect,  he  plays  the  role  of  an  /nnovator  [Rogers,  1983;  Tornatzky  et  al,  1983],  trans¬ 
forming  a  technology  into  something  new. 

While  the  actions  taken  by  people  in  these  roles  supported  RMA  adoption,  there  are  other  fac¬ 
tors  that  also  made  a  strong  contribution.  Next,  we  examine  how  the  existing  organizational 
infrastructure  supported  software  technology  transition  in  general  and  RMA  more  specifically. 

5.2  infrastructure 

ComCo,  Woodville  had  a  number  of  features— particularly,  project  functions— that  aided  the 
adoption  and  application  of  RMA.  Collectively  these  features  compose  an  infrastructure — ^the 
structures  within  the  organization  and  the  formal  and  informal  practices  that  support  the  pro¬ 
cess  of  software  technology  transition.  In  this  section,  we  describe  those  elements  of  the  in¬ 
frastructure  that  supported  the  transition  of  RMA  and  were  mentioned  by  the  interviewees. 
Some  of  the  elements  we  discovered  were  fairly  conventional,  whereas  others  were  atypical. 
For  example,  we  were  less  surprised  by  the  existence  of  a  technology  research  group  to  track 
and  evaluate  new  technology,  internal  research  and  development  (IR&D)  work,  or  mecha¬ 
nisms  for  training  and  education.  More  unusual  were  the  lifetime  employment  policy,  parallel 
career  ladder  for  managers  and  technical  professionals,  a  site-level  software  executive  com¬ 
mitted  to  the  use  of  new  software  technologies,  and  a  proposal  process  for  new  business  that 
allowed  for  the  opportunity  to  introduce  new  technologies  at  a  convenient  time.  We  will  discuss 
each  of  these;  the  more  conventional  structures  first,  followed  by  the  more  unusual  elements. 
Last,  we  look  at  the  site-level  change  agent,  who  belonged  to  the  advanced  technical  solutions 
group.  Since  he  and  his  manager  played  a  key  role  in  support  of  the  introduction  of  RMA,  we 
describe  their  activities  in  greater  detail. 

5.2.1  Technology  Research  Group 

The  technology  research  group  helps  to  keep  ComCo,  Woodville  technologically  competitive 
by  tracking  software  research  and  screening  it  for  application  within  the  site.  We  did  not  inter¬ 
view  the  manager  for  the  group,  although  we  spoke  with  him  briefly Three  interviewees  (all 
managers)  mentioned  the  technology  research  group  and  their  interactions  with  it.  Both  soft¬ 
ware  development  managers  saw  the  research  group  as  a  resource.  AMB,  (avionics  system 
upgrade)  noted  that  she  first  heard  about  RMA  from  the  group  in  1 987-88,  when  she  discussed 


Tornatzky  et  al  [1 983]  make  the  following  distinction:  “Where  this  process  [organizationai  innovation]  begins  with 
a  general  idea  which  becomes  different  things  in  practice,  the  term  adaptation  is  often  used.  Where  a  well-spec¬ 
ified  innovation,  receives  minor  changes,  modification  is  sometimes  found.  Where  a  well-specified  innovation  un¬ 
dergoes  major  change,  the  term  reinvention  has  some  currency”  (p.  136;  italics  Tornatzky  et  al).  PK’s  use  in¬ 
cludes  elements  of  “benign  adaptation”  and  reinvention. 

24.  We  had  asked  our  host,  the  change  agent  (DV),  to  set  up  interviews  with  project  members  who  had  adopted 
RMA  and  with  his  own  manager  (LH).  Also,  DV  arranged  a  technical  interchange  meeting  for  us  on  software  tech¬ 
nology  transfer  with  a  member  of  the  technology  research  group. 


CMU/SEI-93-TR-030 


27 


preparation  of  a  proposal  for  a  time-critical^®  application.  RB  (OCR  project)  referred  to  the 
technology  research  group  when  he  discussed  his  perception  of  the  relevance  of  RMA  to  his 
work  (during  the  mid  1980s).  Later,  he  characterized  the  group  as  “PhDs  looking  at  technolo¬ 
gies  that  people  perceive  are  applicable  to  development  work  they  are  doing.  He  added.  De¬ 
pending  on  the  contract,  I  try  to  draw  from  that  knowledge.”  The  third  interviewee  who 
mentioned  the  research  group  was  the  manager  of  the  advanced  technical  solutions  group 
(LH).  She  referred  to  the  technology  research  group  as  a  “sister  group.” 

Previously,  the  technology  research  group  had  provided  an  organizational  home  for  the  (cor¬ 
porate)  champion  of  RMA  (DL),  and  for  the  change  agent  (DV).  DV  transferred  to  the  ad¬ 
vanced  technical  solutions  group  in  1990,  with  “the  Ada  and  real-time  [system]  people.  Our 
technical  informant  told  us  that  the  site-level  software  manager  (CK)  had  used  the  champion 
(DL)  as  a  high-level  troubleshooter.  The  champion,  in  turn,  used  these  taskings  as  opportuni¬ 
ties  to  apply  RMA  in  solving  problems  and  to  teach  others  about  using  it. 

5.2.2  Internal  Research  and  Development 

Internal  research  and  development  (IR&D)  is  speculative  work  performed  by  government  con¬ 
tractors.  According  to  our  informant,  if,  once  completed,  IR&D  meets  with  government  approv¬ 
al,  the  contractor  firm  is  reimbursed  for  a  percentage  of  the  total  cost.  One  second-level 
manager,  AMB,  said  “lots  of  IR&D  work  helps  groups  like  DARPA^®  explore  technologies  of 
the  future;  can  the  technology  be  applied  to  a  real  task?”  She  noted  that,  using  IR&D  funding, 
her  organization  had  tried  “prototyping,  object-oriented  programming,  an  integrated  develop¬ 
ment  environment  [CASE-like  tools],  and  massively  parallel  processing.”  The  advanced  tech¬ 
nical  solutions  group  manager  (LH)  said  she  “has  a  variety  of  projects— usually  prototypes  or 
something  new,”  that  she  is  trying  to  introduce  to  the  site.  She  decides  what  the  solutions 
group  should  work  on  based  on  a  number  of  factors,  including  what  technologies  are  current, 
what  technologies  Headquarters  is  interested  in,  what  the  hardware  people  are  doing  (“it’s  im¬ 
portant  to  keep  up  with  the  hardware  guys”),  and  what  IR&D  tasks  can  be  funded. 

5.2.3  Training  and  Education  in  the  Application  of  RMA 

Various  forms  of  training  and  education  were  readily  available  to  personnel  at  ComCo,  Wood- 
ville.  For  example,  one  second-level  manager  referred  to  an  “extensive  education  program” 
and  “strong  training  internally”  in  describing  how  design  techniques  for  object-oriented  soft¬ 
ware  were  introduced.  Our  informant  described  a  corporate  training  organization  that  provided 
classroom  training  as  well  as  video  broadcasts  for  executives.  The  advanced  technical  solu¬ 
tions  group  also  sponsored  informal  educational  seminars  for  technical  professionals  and  de¬ 
veloped  videotapes  for  individual  use.  We  consider  all  of  these  mechanisms  and  distribution 
channels  as  part  of  infrastructure  because  they  were  not  only  established  for  RMA;  rather, 
such  forms  of  training  and  education  existed  for  any  new  technology.  Here,  we  sketch  the  in- 

2®-  “Time-criticar  means  that  the  time  taken  to  execute  system  functions  is  extremeiy  limited;  for  example,  a  function 
to  sense  a  change  of  altitude  or  orientation  in  an  aircraft  to  correct  course. 

26-  Defense  Advanced  Projects  Research  Agency,  an  organization  within  the  U.  S.  Department  of  Defense  that 
funds  research,  now  has  a  new  name.  Advanced  Projects  Research  Agency  (ARPA). 
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terviewees’  comments  on  how  the  vehicles  were  used  to  provide  information  and  skills  in  the 
application  of  RMA. 

Our  informant  told  us  that  the  ComCo  corporate  training  organization  generally  developed  its 
own  courses.  In  the  case  of  RMA,  corporate  training  had  funded  part  of  the  informant’s  year 
(1988-89)  as  a  resident  affiliate  at  the  Software  Engineering  Institute  and  had  requested  that 
he  develop  a  course  on  RMA  in  conjunction  with  his  stay.  He  and  other  members  of  the  SEi 
Rate  Monotonic  Analysis  for  Real-Time  Systems  (RMARTS)  Project  prepared  a  tutorial  for  de¬ 
livery  at  three  different  technical  conferences.^^  This  tutorial  was  then  adapted  for  use  at  Com¬ 
Co  and  team-taught,  variously,  by  the  champion  (DL),  the  change  agent  (DV),  and  our 
informant  (TR).  Only  two  of  the  interviewees  mentioned  attending  a  tutorial  on  RMA  at  external 
conferences;  and  no  one  mentioned  attending  ComCo’s  related  corporate  course.  We  can 
only  speculate  about  why  this  was  so.  However,  we  suspect  that  since  all  of  the  interviewees 
had  a  history  of  working  with  the  change  agent  (DV),  they  were  much  more  likely  to  hear  about 
RMA  directly  from  him. 

Later,  the  champion  (DL)  worked  with  corporate  training  to  produce  a  three-hour  version  of  the 
course  for  an  educational  broadcast  to  middle  and  senior  management.  He  eventually  joined 
the  corporate  training  organization  and,  at  the  time  of  the  interviews,  we  learned  that  he  was 
continuing  to  teach  the  full  course.  Apparently,  there  was  need  for  alternative  means  of  com¬ 
munication  about  RMA:  LH,  manager  of  the  advanced  technical  solutions  group,  said  that  the 
change  agent,  DV,  “gets  spread  thin.  I’m  thinking  about  putting  his  talk  on  video.”^® 

5.2.4  A  “Lifetime”  Employment  Policy:  Tenure  and  Trust  Among 
Employees 

Personnel  policies  at  ComCo  resulted  in  de  facto  “lifetime”  employment.  All  but  one  of  the  in¬ 
terviewees,  a  new  employee  who  had  been  at  ComCo  only  3  months,  had  not  worked  else¬ 
where.  Excluding  the  new  employee,  the  average  tenure  of  the  interviewees  was  17  years, 
with  a  range  of  9  to  26  years.  One  individual  was  a  second  generation  ComCo  employee.  The 
informant  corroborated  our  conclusion  that  a  high  level  of  trust  existed  among  the  inter¬ 
viewees,  all  of  whom  knew  each  other.  He  said  most  would  have  “grown  up  together  at  Com- 
Co.”2® 

The  issue  of  trust  was  evident  in  considering  how  the  change  agent  and  the  champion  were 
viewed  as  reliable  and  credible  sources  of  information  about  RMA  (with  only  one  individual 
learning  about  RMA  from  an  outside  source).  Our  informant  summarized  as  such:  prospective 
users  of  any  new  technology  asked  three  questions  of  its  proponents: 


^^  TriAda;  IEEE  Real-Time  Systems  Symposium;  and  the  SEI  Software  Engineering  Symposium. 

This  taik  was  one  in  a  series  of  lunchtime  seminars  sponsored  by  the  soiutions  group.  The  change  agent,  DV, 
and  a  colleague  presented  information  about  RMA. 

Personal  interviews  with  TR,  October  and  November  1991. 
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1 .  Will  it  help  me? 

2.  Have  you  used  it? 

3.  Will  you  help  me? 

If  the  answers  to  all  three  questions  were  “yes,”  then  people  were  convinced  to  use  the  tech¬ 
nology,  in  this  instance  RMA.  More  “objective”  proof  of  its  worth,  such  as  factual  measures  of 
improved  quality  and  productivity,  were  not  as  important  as  the  judgment  and  competence  of 
their  long-time  peers.  We  suspect  that  these  “objective”  measures  would  play  a  more  signifi¬ 
cant  role  when  dealing  with  outsiders,  for  example,  if  a  vendor  suppled  the  technology.  Then, 
a  different  credibility  check  might  occur. 

5.2.5  Parallel  Technical/Managerial  Promotion  Paths 

ComCo  has  parallel  career  paths  for  managers  and  technical  personnel:  managers  progress 
through  one  set  of  job  classifications,  and  technical  personnel  through  a  different  but  equiva¬ 
lent  set.  Our  informant  explained  that  because  of  this,  even  though  very  senior  technical  peo¬ 
ple  may  report  administratively  to  lower  level  managers,  they  interact  freely  and  directly  with 
senior  managers.  As  noted,  our  informant  told  us  that  the  senior  software  manager  at  Wood- 
vjlle,  CK— who  was  also  the  initiating  and  sustaining  sponsor— used  the  champion,  DL,  for 
technical  troubleshooting  while  he  (DL)  reported  to  the  manager  of  the  research  group.  Our 
informant  felt  that  the  senior  manager,  CK,  sought  the  champion’s  judgment  based  on  expe¬ 
rience  and  expertise  rather  than  detailed  technical  information.  The  senior  manager  commu¬ 
nicated  directly  with  the  champion,  avoiding  the  filtering  by  intervening  levels  that  might  occur 
in  a  single-ladder  system. 

Another  effect  of  the  dual  ladder  is  that  new  technology  receives  direct  consideration  at  multi¬ 
ple  levels  of  the  organization.  Senior  technical  people  influenced  the  early  use  of  immature 
technologies.  Both  of  the  second-level  managers  (AMB  and  RB)  expressed  interest  in  RMA 
and  other  new  technologies.  RB  (OCR  project)  said,  “I’m  impatient  RMA  is  not  getting  imple¬ 
mented  faster.  I  think  it  is  a  key  technology  we  should  be  embracing.  But  I’m  part  of  the  prob¬ 
lem  because  I’m  not  mandating  it.  I  can  advocate  but  not  dictate.”  Thus,  technical  personnel 
were  able  to  take  the  lead  in  choosing  to  apply  new  technologies;  and  the  existence  of  tech¬ 
nical  staff  at  higher  ranks  increased  the  number  of  organizational  “pores”  through  which  tech¬ 
nologies  could  flow  into  ComCo  (Kanter,  1983;  pp.  204-205,  359). 

5.2.6  Site-Level  Software  Executive 

In  Section  5.1 ,  the  discussion  of  roles,  we  commented  on  the  importance  of  an  initiating  spon¬ 
sor,  usually  a  senior  executive.  Any  senior  executive  can  serve  as  a  sponsor;  however,  when 
the  sponsorship  role  is  institutionalized,  as  was  the  case  of  the  executive  responsible  for  soft¬ 
ware  (as  a  separate  organization)  at  Woodville,  the  role  and  function  must  also  be  considered 
as  infrastructure.  At  the  time  of  the  interviews,  this  executive  (CK)  had  transferred,  and  the  po¬ 
sition  no  longer  existed.  Nonetheless,  according  to  two  software  engineers  (GP  and  SN),  CK 
played  a  significant  role  in  supporting  RMA  adoption  early  on;  they  felt  the  presence  of  an  ex- 
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ecutive  for  software  was  critical  to  Woodville’s  being  “ahead  of  the  state  of  the  art  in  software.” 
CK  was  mentioned  in  conjunction  with  Woodville’s  “good  process”  for  software  along  with  a 
range  of  software  development  practices  considered  exemplary 

5.2.7  Proposals  Process 

The  timing  of  technology  introduction  is  important  [Fiman,  1989;  Bouldin,  1989;  Tyre  &  Or- 
likowski,  1993].  People  resist  the  change  associated  with  new  technologies  if  they  have  re¬ 
cently  adopted  other  technologies,  if  the  organization  is  under  stress  (for  example,  due  to  a 
takeover),  or  if  the  status  quo  is  perceived  as  adequate.  Thus,  having  a  point  in  the  work  pro¬ 
cess  where  technology  can  be  introduced  routinely  can  expedite  the  introduction  of  a  new 
technology.  At  ComCo,  Woodville,  the  proposals  process  provided  this  opportunity. 

The  Woodville  site  works  primarily  as  a  government  contractor,  using  the  proposal  and  bidding 
process  to  win  business.  The  process  was  viewed  by  the  interviewees  as  a  natural  point  for 
the  incorporation  of  new  technologies.  For  example,  three  members  of  technical  staff,  inter¬ 
viewed  as  a  group  (TK,  senior  software  engineer;  and  BH  and  JO,  software  engineers)  listed 
eight  technologies  in  addition  to  RMA  that  they  had  “explored  or  used  on  a  trial  basis”  for  the 
development  of  a  system  that  they  were  proposing.  (They  viewed  the  introduction  and  use  of 
these  technologies  not  as  risks  but  as  “risk  mitigators.”)  The  manager  of  the  advanced  techni¬ 
cal  solutions  group,  LH,  “tried  to  make  people  aware  of  what’s  there”  in  the  way  of  useful  tech¬ 
nologies.  She  saw  it  as  “her  business  to  know  what’s  starting,  to  know  when  to  send  [the 
change  agent,  DV]  out.”  The  solutions  group  was  “very  active  in  the  proposal  stage,  because 
it’s  where  the  tone  is  set  for  what  happens.”  LH  observed  that,  at  the  time  of  the  interviews, 
things  were  slow:  “Not  as  many  projects  are  starting,  so  there  are  not  as  many  opportunities 
to  introduce  [new  technologies].” 

In  1 990,  during  an  effort  to  determine  whether  to  prepare  a  proposal,  one  member  of  the  tech¬ 
nical  staff,  TK,  senior  software  engineer,  said  he  was  assisted  by  the  champion  in  using  RMA 
to  “judge  risk  on  behalf  of  ComCo  in  doing  a  proposal.”  (This  was  the  engineer’s  first  exposure 
to  RMA.)  Another  member  of  technical  staff,  BH,  software  engineer,  noted  that  he  was  on  a 
proposal  team  for  a  new  system  and  was  “delighted  the  decision  was  made”  to  use  RMA.  The 
manager  of  the  avionics  systems  upgrade,  AMB,  said  we  “try  to  insert  at  least  one  new  tech¬ 
nology  in  each  program.”  The  OCR  system  manager,  RB,  said  that  new  technologies  are  tried 
“depending  on  the  contract”  and  that  suggestions  came  from  “people  who  keep  up  with  what’s 
going  on.”  PK,  distinguished  fellow  and  project  manager  for  the  Al  system,  discussed  the  use 
of  RMA  in  writing  a  proposal  for  a  precursor  to  the  system  he  was  working  on. 

While  interviewees  described  the  use  of  RMA  at  various  times,  the  process  of  preparing  pro¬ 
posals  offered  a  special  window  of  opportunity  to  consider  the  application  of  RMA  and  other 
new  technologies  in  their  work.  When  a  system  was  already  under  development,  it  was  more 

These  included  “a  structured  approach  to  requirements  definition,  high-level  design,  and  low-level  design;  pro¬ 
totyping  and  ‘spiral’  development;  an  independent  test  group,  a  software  quality  organization,  and  a  language  for 
design  independent  of  [software]  implementation;  and  software  inspections.”  These  practices  were  identified  by 
GP  and  SN,  software  engineers. 
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difficult  to  find  time  and  funding,  and  often  these  engineers  were  adapting  or  adding  to  existing 
systems.  RB  (OCR  system  manager)  said,  “We  can’t  find  money  to  do  RMA  when  reusing  sys¬ 
tems  that  already  exist.” 

5.2.8  Advanced  Technical  Solutions  Group 

The  advanced  technical  solutions  group  was  the  organizational  home  for  DV,  the  change 
agent.  The  existence  of  this  group  made  it  possible  for  him  to  learn  about  RMA  on  behalf  of 
the  programs  at  the  site  and  disseminate  his  expertise.  We  briefly  describe  the  group  and  then 
the  RMA  change  agent  located  within  it. 

The  solutions  group  acted  as  gatekeeper  and  boundary  spanner ,  tracking  technology  and  fil¬ 
tering  it  on  behalf  of  the  site.  Members  of  the  group  also  acted  as  change  agents,  with  respon¬ 
sibility  to  disseminate  and  support  the  initial  use  of  technologies  (including  RMA)  new  to  the 
site.  According  to  the  manager,  LH,  the  group  “introduces  Ada  technology  and  real-time  tech¬ 
nology  into  the  software  world  on  site.  Our  job  is  to  be  a  source  of  help  resolving  development 
problems.”  Group  members  gain  knowledge  of  new  technology  by  attending  lots  of  confer¬ 
ences,”  by  performing  small  internal  R&D  projects,  and  by  subcontracting  pieces  of  work  from 
programs  elsewhere  on  site.  The  manager  indicated  that  some  technology  is  brought  into  the 
solutions  group  by  members  who  have  worked  at  other  sites:  people  in  the  advanced  technical 
solutions  group  often  come  out  of  development  programs,  and  then  eventually  transfer  back 
into  development,  taking  their  knowledge  and  experience  with  new  technologies  along  with 
them.  Some  technology  “comes  in  the  door”  via  word  of  mouth,  advertising  materials,  and  pro¬ 
fessional  and  technical  journals.  The  technologies  that  they  identify  as  potentially  useful  pro¬ 
vide  an  inventory  from  which  they  draw  to  supply  others. 

LH  (manager)  and  the  solutions  staff  also  track  needs  at  a  corporate  and  program  level.  They 
work  closely  with  headquarters  to  understand  programs  and  “what  they  are  interested  in  ,  and 
the  solutions  group  looks  at  what  contracts  are  coming.  They  follow  new  proposals  and,  as 
described  earlier,  identify  the  use  of  new  technologies  during  proposal  preparation. 

The  advanced  technical  solutions  group  worked  in  a  number  of  modes.  They  disseminated  in¬ 
formation,  for  example,  through  “technical  vitality”  seminars  at  lunch  time  (used  with  RMA)  and 
training  courses,  such  as  the  one-and-one-half  day  course  on  RMA.  They  created  demonstra¬ 
tions:  for  RMA,  the  change  agent  (DV)  prepared  software  to  demonstrate  RMA  principles.  So¬ 
lutions  staff  served  as  consultants  to  development  projects.  According  to  DV,  consultations 
could  be  as  simple  as  answering  a  phone  inquiry  or  distributing  a  technical  paper,  or  might  in¬ 
volve  weeks  of  work  alongside  system  developers.^^  Solutions  group  members  knew  they 
were  finished  working  in  a  technical  area  “when  all  lead  technical  people  know”  [LH,  manager] 
and  when  they  “get  beyond  the  point  of  knowing  to  call”  [DV,  the  change  agent]. 

The  manager  of  the  advanced  technical  solutions  group,  LH,  had  a  strong  intuitive  understand¬ 
ing  of  how  to  bring  technology-based  solutions  to  programs  and  projects  at  ComCo,  Woodville. 
In  particular,  she  spoke  at  length  about  the  type  of  people  who  were  most  effective  in  her 

If  solutions  staff  were  needed  as  consultants  for  a  “block  of  time,”  the  program  using  them  provided  funding. 
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group.  She  said  they  “must  have  a  feel  for  what  many  people  are  doing  and  talk  in  their  lan¬ 
guage.”  They  have  to  “make  it  less  abstract  [and]  talk  to  them  [their  clients]  when  they  have  a 
problem.”  LH  observed  that  people  on  her  staff  “must  be  very  flexible.  No  serial  operators.” 
Solutions  staff  must  have  “parallel  circuits,”  and  they  “need  a  variety  of  personalities  and  tech¬ 
niques:  people  may  be  less  strong  with  technologies  but  better  able  to  relate  to  other  groups.” 
LH,  herself,  stays  in  touch  with  other  managers.  Advocacy  and  salesmanship  were  critical:  it 
was  her  business  to  know  who  was  starting  what  and  to  make  people  aware  of  what  was  avail¬ 
able.  Her  staff  was  “always  looking  for  what  they  have  to  show  for  their  efforts.” 

The  solutions  group  manager  had  a  number  of  characteristics  typical  of  an  effective  change 
agent.  She  was  “cosmopolite”  [Rogers,  1983];  while  she  had  spent  her  professional  life  in  soft¬ 
ware  at  ComCo,  Woodville,  she  had  “always  [held]  different  jobs.”  She  acted  as  a  boundary 
spanner  and  was  aggressive  in  making  contact  with  other  technical  managers.  LH  sought 
them  out,  found  ways  to  assess  their  needs,  and  appeared  to  enjoy  such  interaction.  She  un¬ 
derstood  “salesmanship”  and  had  a  strong  customer  orientation.  LH  remarked  that  she  saw 
the  change  agent’s  promotion  to  a  more  senior  position  as  a  “good  sign  of  appreciation” — an 
indication  that  her  customers  understood  and  appreciated  the  services  her  group  provided. 

At  the  time  we  conducted  the  inten/iews,  DV,  the  change  agent  for  RMA,  had  been  in  the  so¬ 
lutions  group  for  roughly  three  years.  Previously,  he  had  been  a  member  of  the  research 
group.  He  had  been  at  ComCo,  Woodville  for  25  years  and  had  worked  with  or  knew  most  of 
the  interviewees  before  his  involvement  in  RMA.  According  to  the  interviewees  and  our  infor¬ 
mant,  DV  had  an  excellent  reputation  as  a  consultant,  in  addition  to  domain  expertise  and  skills 
related  to  RMA  technology.  He  was  instrumental  in  developing  software  that  demonstrated 
RMA.  Because  of  the  range  of  consulting  experiences  he  had  with  RMA,  he  was  able  to  de¬ 
velop  heuristics  for  the  application  of  RMA  in  many  situations.  The  latter  sustained  and  in¬ 
creased  the  demand  for  his  services.  DV’s  technical  expertise  and  his  official  base  in  the 
solutions  group  were  critical  to  ComCo,  Woodville’s  application  of  RMA. 

The  change  agent  was  viewed  as  a  resource  by  managers  as  well  as  by  members  of  the  tech¬ 
nical  staff.  Both  software  development  managers  (RB  and  AMB)  had  contact  with  DV  regard¬ 
ing  RMA.  AMB  (avionics  system  upgrade  project)  mentioned  studies  done  “by  the  [change 
agent/solution]  group.”  RB  (OCR  project)  noted  that  the  change  agent  “was  always  concerned 
with  predictability,  especially  in  the  Ada  world.”^^  In  1991 ,  RB  “asked  that  teams  get  briefed 
[by  DV]  and  apply  RMA  to  what  they  were  doing.”  The  change  agent  did  brief  them  and  used 
the  university-developed  tool  for  demonstration. 


32-  According  to  our  technical  informant,  this  meant  the  “world”  of  Ada  compiler  development. 
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All  the  personnel  we  interviewed,  except  PK,  the  distinguished  fellow,  had  assistance  in  ap¬ 
plying  RMA  from  the  change  agent.  In  one  case,  when  DV  was  looking  for  a  pilot  of  RMA  con¬ 
cepts,  he  had  a  cost  center  that  others  could  charge  to.  This  was  apparently  almost  as 
important  as  his  technical  credibility.  According  to  one  member  of  technical  staff,  GP,  software 
engineer,  involved  in  that  pilot,  RMA 

had  a  good  salesman...  enthusiastic,  dedicated  to  seeing  it  work.  If  I  hadn  t 
known  [the  change  agent],  I  wouldn’t  have  used  it.  I  might  have  turned  him 
down  if  he  hadn’t  brought  funding. 


Three  members  of  technical  staff  from  another  project  (TK,  BH,  and  JO)  observed  that  their 
use  of  RMA  still  depended  on  outside  expertise.  BH  commented  that  RMA 


...concepts  are  relatively  simple  to  grasp;  modeling  a  system  is  much  more 
difficult.  ...No  one  has  taken  it  to  a  large  system.  It  would  be  nice  to  have  [the 
change  agent]  or  [the  champion]  for  a  couple  of  weeks. 

Another,  TK,  senior  software  engineer,  noted  that 

RMA  can  be  applied  at  a  couple  of  levels:  (1)  simple-minded  application  to  give 
grasp  of  general  characteristics  of  a  system  ...  and  (2)  analysis  of  problem 
stage:  a  whole  different  level  of  understanding— [the  change  agent] ...  can  help. 


DV’s  “official”  role  as  consultant  for  those  trying  to  use  new  software  technologies  made  it 
more  likely  that  he  would  be  used  and  that  the  technologies  he  was  purveying  would  also  be 
used.  Had  DV  been  working  as  a  member  of  a  project  assigned  to  development,  even  with  his 
enthusiasm  and  expertise  for  RMA,  he  would  have  had  only  limited  time  to  apply  to  the  tech¬ 
nology.  Given  the  difficulty  of  application,  it  is  unlikely  RMA  would  have  been  used  by  others 
without  dedicating  DV  as  a  resource.  Locating  him  (and  others  like  him)  within  the  advanced 
technical  solutions  group  provided  the  organization  with  a  resource  (both  time  and  expertise) 
that  they  could  draw  from  as  necessary.  Thus,  the  solutions  group  was  a  major  piece  of  the 
infrastructure  supporting  the  adoption  and  implementation  of  RMA. 
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5.3  An  Innovative  Culture 


An  innovative  organization  responds  rapidly  to  changing  conditions  in  its  environment  by  virtue 
of  its  openness  [Kanter,  1 983],  its  flexibility  [Peters  &  Waterman,  1 982],  and  its  ability  to  “learn” 
[Morgan,  1986;  Kim,  1994].  ComCo,  Woodville’s  innovativeness  is  shown  partly  through  the 
infrastructure  that  allowed  Woodville  to  absorb  new  technologies.  It  is  also  present  in  its  cul¬ 
ture,  the  set  of  “patterns  of  belief  or  shared  meaning”  that  guide  the  actions  of  its  employees 
(Morgan,  1986,  p.  121).  In  this  section  we  examine  the  aspects  of  culture  that  we  believe  ex¬ 
pedited  the  adoption  of  RMA  as  an  immature  technology.  These  aspects,  all  connected  to  the 
value  placed  on  new  technology,  include 

•  Viewing  new  technologies  as  risk  mitigators. 

•  The  value  of  developing  and  rewarding  the  technical  professional. 

•  The  benefit  of  resources  allocated  to  technology  acquisition  and 
implementation. 

•  The  value  placed  on  organizational  learning. 

5.3.1  New  Technologies  as  Risk  Mitigators 

Because  of  the  impact  of  technological  change  on  organizations,  adopting  new  technologies 
is  often  viewed  as  inherently  risky  [Fiman,  1 989].  This  was  not  the  case  at  ComCo,  Woodville. 
Two  of  the  senior  members  of  technical  staff,  TK,  senior  software  engineer,  and  BH,  software 
engineer,  reported  that  they  saw  the  adoption  and  implementation  of  new  technologies  as  “risk 
mitigation,”  not  risk.  They  also  said  new  technologies  provided  them  with  better  and  some¬ 
times  cheaper  ways  to  accomplish  technical  work,  and  with  competitive  advantage,  although 
they  “look  for  tools  that  fit  into  our  process  and  not  vice  versa."  RB,  manager  of  OCR  software 
development,  told  us  that  they  expected  to  maintain  a  “level  of  know-how”  and  that  “competi¬ 
tive  pressure  pushes  this.”  AMB,  manager  of  the  avionics  systems  upgrade,  sought  out  “les¬ 
sons  learned”  papers,  where  experiences  with  new  technologies  or  with  problems  that  might 
respond  to  new  technologies  were  described;  she  also  mentioned  reading  technical  papers  on 
RMA  and  looking  at  studies  done  by  the  solutions  group.  PK,  the  distinguished  engineer,  re¬ 
marked  that  RMA  made  a  difference  in  a  proposal  award;  he  saw  including  RMA  in  the  pro¬ 
posal  as  an  opportunity  rather  than  a  risk. 

5.3.2  Developing  and  Rewarding  the  Technical  Professional 

ComCo,  Woodville  invested  in  its  employees.  This  was  clear  in  three  ways: 

1 .  Woodville  personnel  had  access  to  continuing  education  in  a  variety  of  forms. 

2.  The  dual  career  ladder  gave  those  interested  in  a  technical  career  the 
opportunity  to  grow  and  influence  the  direction  of  the  organization. 

3.  The  “lifetime”  employment  policy  gave  employees  a  secure  context  within 
which  to  take  risks,  including  technological  risks,  on  behalf  of  the  firm. 
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Woodville  employees  could  take  advantage  of  a  range  of  opportunities  for  developing  new 
technical  skills  and  knowledge,  including  seminars  and  training  courses.  Funds  were  available 
for  attending  conferences.  For  example,  the  IEEE  Real-Time  Systems  Symposium  and  TriAda 
conferences  were  referred  to  by  name  by  two  members  of  the  technical  staff.  LH,  manager  of 
the  solutions  group,  noted  that  she  and  her  group  “go  to  lots  of  conferences.”  AMB,  (manager, 
avionics  system  upgrade)  mentioned  an  “extensive  education  program”  and  “strong  training 
internally”  at  Woodville.  Another  member  of  the  technical  staff,  GP,  software  engineer,  noted 
that  as  they  “moved  toward  object-orient[ation]”  they  obtained  “training  as  needed,  and  now  it 
is  offered  as  initial  training  to  new  programmers.” 

According  to  our  informant,  employees  worked  with  their  managers  to  develop  annual  training 
plans:  all  personnel  were  expected  to  attend  training  and  continuing  education  courses,  and 
time  was  allocated  for  them  to  do  so,  despite  demanding  project  schedules.  We  asked  our  in¬ 
formant  if  ComCo  viewed  training  and  continuing  professional  education  for  its  technical  and 
managerial  employees  as  a  perquisite  or  as  a  strategic  investment.  He  replied  that  it  was 
“somewhere  in  between,”  because  employees  were  responsible  for  choosing  their  own  train¬ 
ing,  but  training  was  included  in  personal  objectives,  reviewed  by  one’s  manager,  and  paid  for 
by  the  corporation.  Also,  promotion  was  linked  to  competence,  which  in  turn  required  continual 
upgrading  of  technical  skills.  And  ComCo  benefitted  overall  as  well  because  its  employees 
were  technically  current. 

In  keeping  with  the  value  placed  on  training  and  education,  ComCo  employees  had  access  to 
skills  and  knowledge  about  RMA.  ComCo’s  corporate  education  had  paid  for  the  development 
of  an  RMA  seminar  by  partly  funding  the  SEI  resident  affiliate  (our  informant,  TR).  The  seminar 
was  tailored  to  ComCo,  and  the  champion  (DL)  taught  it  a  number  of  times,  across  the  corpo¬ 
ration.  The  change  agent  (DV)  also  taught  the  seminar  in  Woodville  and  presented  a  short 
lunchtime  version  with  a  colleague.  The  manager  of  the  advanced  technical  solutions  group 
said  she  was  considering  development  of  a  videotape  of  an  RMA  presentation  by  the  change 
agent:  she  clearly  had  funds  at  her  discretion  to  do  this. 

The  dual  career  ladder,  described  in  Section  5.2,  provided  parallel  technical  and  managerial 
promotion  paths.  By  enabling  technical  professionals  to  move  into  positions  of  influence,  it  al¬ 
lowed  technology  to  affect  business  direction.  Both  the  champion  (DL),  in  the  next-to-highest 
technical  rank,  and  the  change  agent  (DV)  ranked  just  below  the  champion,  held  positions  that 
required  others  to  take  their  opinions  on  RMA  seriously,  and  encouraged  others  to  trust  in  their 
counsel. 

The  longevity  of  tenure  of  all  but  one  interviewee,  including  our  informant,  seemed  to  reinforce 
the  value  of  calculated  technological  risk.  Employees’  jobs  were  not  at  stake  when  they  made 
decisions.  Our  informant  said  that  there  was  “very  little  personal  risk.  Because  even  if  you  blow 
it  big  time,  you’re  not  going  to  lose  your  job.”  He  told  us  about  a  mistake  he  made  early  in  his 
career  at  ComCo: 
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My  boss  called  me  in  and  said  “You’ve  got  to  understand  something.  If  you  blow 
it  here  at  [ComCo]  for  $10,000,  i’m  going  to  give  you  $100,000  responsibility 
because  I  know  you  won’t  make  the  $10,000  mistake  again.  And  if  you  blow  it 
at  $100,000,  I’ll  give  you  a  $1,000,000  responsibility  because  you  already 
learned  those  lessons... that’s  what  it’s  about  here.”  And  so  [about]  this 
longevity,  there  is  no  perceived  personal  risk  other  than  to  reputation.  But 
remember,  reputation  is  very  important  for  moving  up  the  ladder.  It  means  a  lot. 

So,  in  terms  of  your  paycheck,  there’s  not  a  personal  risk  here.  So  what  you 
risk  is  your  reputation. 

We  commented,  to  our  informant,  that  this  seemed  to  create  a  situation  where  everyone  would 
want  to  do  well.  He  replied,  “Exactly.” 

5.3.3  Resources  Allocated  to  Technology  Acquisition  and 
Implementation 

Interviewees  expressed  interest  in  obtaining  new  technology  that  would  help  them  do  their 
jobs  more  effectively.  They  looked  especially  to  the  champion  (DL)  and  the  change  agent  (DV) 
for  information  and  consulting  support.  Thus,  one  way  to  view  the  champion  and  the  change 
agent  is  as  “slack”  resources— resources  that  are  not  assigned  to  specific  contracts,  but  that 
are  available  for  unanticipated  tasks  that  must  be  accomplished,  such  as  troubleshooting, 
tracking  and  screening  new  technologies,  and  consulting.^^ 

The  champion  was  a  slack  resource,  being  a  very  senior  person  who  worked  partly  at  his  own 
discretion  and  partly  on  request  by  senior  management  to  solve  problems  across  the  corpo¬ 
ration  (not  just  at  Woodville).  The  change  agent  also  was  available  for  consulting,  and  this 
work  was  funded  by  the  budget  of  the  advanced  technical  solutions  group.  Three  interviewees 
learned  about  RMA  through  other  sources,  such  as  the  original  Liu  and  Layland  paper  or  con¬ 
ference  seminars.  PK,  distinguished  fellow,  used  the  paper  to  determine  by  himself  how  to  ap¬ 
ply  RMA,  but  the  other  two,  AMB,  manager,  and  GP,  software  engineer,  used  the  change 
agent  as  a  resource  when  it  came  to  application  in  their  programs. 

The  technology  research  group  and  the  advanced  technical  solutions  group  can  also  be  seen 
as  slack  resources  because  they  were  not  dedicated  to  contracts  or  product  development. 
(While  the  solutions  group  did  perform  subcontracted  work  and  IR&D,  it  did  so  to  “keep  its 
hand  in”  and  to  support  its  primary  task:  tracking  and  assisting  with  the  use  of  new  technology. 
Both  groups  were  mentioned  by  the  two  software  development  managers  as  resources  for 
new  technology.  ComCo,  Woodville  treated  these  as  “official”  slack  resources  by  assigning 
managers  and  technical  personnel,  full  time,  and  by  providing  them  with  funding.®'^ 

The  champion  (DL),  the  technology  research  group,  and  the  change  agent  (DV)  and  the  ad¬ 
vanced  technical  solutions  group  that  he  belonged  to  were  dedicated  to  looking  ahead  for  an¬ 
swers  to  emerging  needs,  identifying  and  sharing  information  on  these,  and  then  providing 

^  Rogers  [1983]  notes  that  slack  resources  more  frequently  occur  in  larger  organizations  (p.  359).  Damanpour 
[1991]  associates  slack  resources  with  more  innovative  organizations  (p.  562). 

An  example  of  “unofficial”  slack  resources  is  when  managers  “pad”  their  budgets  to  allow  for  expansions  and 
contractions  in  workload. 
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assistance  in  their  assimiiation.  In  this  respect,  they  function  as  advanced  technology  groups: 
their  job  is  “not  only  to  evaluate  new  concepts  but  to  implement  strategic  technologies  as  well” 
(Santosus,  1994,  p.  56).  By  reserving  people  to  anticipate  future  directions  in  technology  and 
to  respond  to  demand  for  application  of  identified  technologies,  ComCo,  Woodville  remains 
flexible  and  open,  ready  to  innovate  when  it  makes  sense  to  do  so. 

5.3.4  Organizational  Learning 

The  change  agent  (DV)  and  the  champion  (DL)  also  represent  a  form  of  organizational  learn¬ 
ing.  They  are  able  to  work— at  corporate  and  site  levels— in  a  way  that  allows  them  to  gain 
broad  experience.  They  see  how  one  technology,  RMA,  can  be  applied  in  many  different  ways. 
Thus,  ComCo  “learns”  how  to  apply  RMA  in  a  range  of  situations.  No  one  program  can  provide 
that  range  of  opportunities  within  a  reasonable  time  period.  For  example,  each  interviewee 
with  whom  the  change  agent  or  the  champion  worked  mentioned  the  application  of  RMA  as 
something  that  occurred  only  once  or  twice.  Because  the  change  agent  and  the  champion  can 
gain  much  broader  experience,  the  corporation  benefits  each  time  they  work  to  help  a  program 
apply  the  technology.  They  draw  from  singular  experiences  in  specific  settings  and  gradually 
build  an  important  competency  that  can  be  applied  to  competitive  advantage  in  building  soft¬ 
ware  for  real-time  systems. 

5.4  Innovation-Decision  Process 

The  literature  on  diffusion  and  transfer  carries  implicit  assumptions  about  the  “adoption”  of  an 
innovation,  including  the  rate  of  its  spread  and  the  characteristics,  or  attributes,  of  the  innova¬ 
tion  [Augliere,  1994;  Downs  &  Mohr,  1976;  Tornatzky  &  Klein,  1982].  The  data  gathered  in 
these  interviews  on  the  adoption  and  implementation  of  RMA  raise  questions  about  underlying 
assumptions  in  diffusion  theory.  Here,  we  are  primarily  concerned  with  two  aspects: 

1 .  How  individuals  in  an  organization  come  to  “adopf — ^the  innovation-decision 
process — [Conner  &  Patterson,  1982;  Rogers,  1983]. 

2.  What  it  is  that  is  adopted,  namely  the  nature  of  the  technology  as  revealed  by 
users’  perceptions  of  its  attributes  [Fichman  &  Kemerer,  1993;  Rogers,  1983; 
Tornatzky  &  Fleisher,1990;  Tornatzky  &  Klein,  1982]. 

Traditional  approaches  to  diffusion  assume  a  universally  applicable  process  of  adoption;  how¬ 
ever,  our  findings  indicate  that  the  processes  of  adopting  and  implementing  RMA,  as  well  as 
perspectives  on  the  technology’s  use,  were  not  uniform.  In  this  section,  we  consider  the  deci¬ 
sion-making  aspects  during  the  early  stages  of  commitment,  before  and  up  to  trial.  In  Section 
5.5,  we  concentrate  on  the  attributes  of  RMA:  the  degree  to  which  the  technology  was  per¬ 
ceived  as  advantageous,  complex,  trialable,  etc.  The  discussion  on  attributes  picks  up  with  the 
later  stages  of  commitment,  during  trial  and  pilot  use.  The  innovation-decision  process  and  the 
attributes  of  innovations  are  related:  one’s  perception  of  an  innovation  affects  the  decision  to 
adopt  and  implement.  However,  for  the  sake  of  clarity  we  consider  these  themes  separately 
and  note  places  of  overlap. 
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Rogers  [1983]  defines  the  innovation-decision  process  as  “the  process  through  which  an  indi¬ 
vidual  (or  other  decision-making  unit)  passes  from  first  knowledge  of  an  innovation,  to  forming 
an  attitude  toward  the  innovation,  to  decision  to  adopt  or  reject,  to  implementation  of  the  new 
idea,  and  to  confirmation  of  this  decision”  (p.  165).  His  model  of  the  stages  of  the  innovation- 
decision  process  includes 

•  Knowledge 

•  Persuasion 

•  Decision 

•  Implementation 

•  Confirmation 

Similariy,  Conner  &  Patterson  [1982]  treat  the  process  of  building  commitment  for  change  in 
terms  of  three  phases. 

•  Phase  1 ,  Preparation,  includes  the  stages  of  contact  and  awareness. 

•  Phase  2,  Acceptance,  involves  understanding  the  change  and  positive 
perception. 

•  Phase  3,  Commitment,  inciudes  instaliation,  adoption,  institutionalization, 
and  internaiization. 

With  respect  to  the  individuais  we  interviewed  about  RMA,  we  did  not  see  evidence  of  a  unitary 
commitment  process,  although  we  did  see  patterns  of  behavior,  decision  making,  and  influ¬ 
ence.  As  already  noted,  our  informant  summarized  his  impression  of  the  innovation-decision 
process  succinctly:  an  individual  at  ComCo  would  be  seeking  answers  to  the  following  ques¬ 
tions:  Will  it  (the  technology)  help  me?  Have  you  used  it?  and.  Will  you  help  me?  In  this  regard, 
we  see  a  connection  between  the  processes  of  commitment  and  of  problem  solving.  Rogers 
[1 983]  alludes  to  this  connection  when  he  notes  that  the  diffusion  of  an  innovation  is  an  “un¬ 
certainty-reduction  process”  (p.217),  but  he  fails  to  observe  that  risk  and  uncertainty  reduction 
typically  occur  at  at  least  two  levels: 

1 .  In  response  to  the  original  need  or  problem  that  exists  separate  from  the  in¬ 
novation  (the  problem  that  the  innovation  or  technology  may  be  attempting  to 
address). 

2.  With  respect  to  the  uncertainty  associated  with  the  technology  itself. 

Rogers’  limited  interpretation  of  risk  and  uncertainty  reduction  may  be  a  natural  consequence 
of  his  preoccupation  with  diffusion  as  purchase  oi  consumer  goods  and  services.  The  adoption 
and  implementation  of  new  technologies  to  solve  technical  and  business  problems  is  a  differ¬ 
ent  matter. 

The  avionics  software  development  manager  (AMB)  responded  to  this  precise  issue:  to  risk 
reduction  in  the  project  (as  opposed  to  the  uncertainty  reduction  associated  with  RMA  tech¬ 
nology).  When  asked,  “How  will  you  decide  whether  to  continue  using  RMA?”,  she  responded: 
“I  don’t  think  we  have  an  alternative.  A  program  of  this  complexity — I  can’t  afford  to  not  know 
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what’s  happening  in  that  box  at  any  given  time.  I  would  think  we’d  use  it  (RMA)  through  each 
phase — primarily  up  front  but  also  to  understand  changes  and  the  consequences  of  those 
changes.”  A  senior  software  engineer  on  the  same  project,  TK,  toid  us:  “Hi-defined  problems 
are  the  problem,  not  just  the  introduction  of  new  techniques,  tools,  and  people.” 

Moreover,  we  observed  how  perceptions  of  risk  reduction  for  technical  problems  and  uncer¬ 
tainty  reduction  with  respect  to  new  technology  varied  in  level  of  granularity.  For  example,  two 
of  the  engineers  on  the  avionics  system  upgrade  project  both  “adopted”  RMA  technology,  but 
at  different  levels.  Our  informant  used  an  aerial  metaphor  to  illustrate  the  distinction.  In  his 
view,  the  senior  software  engineer  was  concerned  with  adopting  the  technology  and  with  as¬ 
sociated  risks  at  the  highest  level,  at  “300,000  feet.”  The  senior  engineer  (TK)  remarked:  “If  it 
pans  out,  we’ll  have  a  system  that’s  predictable,  and  we’ll  have  a  better  product.”  On  the  other 
hand,  the  informant  thought  that  TK’s  colleague,  a  somewhat  more  junior  software  engineer 
(BH),  was  operating  at  “30,000  feet.”  When  we  asked  BH  if  RMA  helped  him  to  do  things  better 
than  he  had  before,  he  responded  cautiously.  He  said,  “Ideally,  but  it’s  eariy.  The  concepts 
were  relatively  easy  to  grasp  in  class;  modeling  a  system  will  not  be  so  easy.”  What  was  inter¬ 
esting  to  us  was  the  informant’s  conclusion:  he  observed  that  if  BH  was  successful  at  imple¬ 
mentation — ^at  modeling  the  system — his  senior  colleague  would  never  need  to  get  the  more 
detailed  look  at  the  lower  level  application  problems.  Typically  we  might  assume  that  project 
members  benefit  from  sharing  the  same  perspective;  however,  here,  the  two  perspectives  are 
different  and  possibly  more  efficient  because  of  their  wider  compatible  scope. 

We  cannot  generalize  about  the  benefits  of  complementary  or  divergent  perspectives  about  a 
technology;  however,  attention  to  the  “degree  to  which  individuals  converge  in  the  meaning- 
space  of  their  common  experience”  may  help  us  to  consider  the  role  of  concurrence  in  an  in¬ 
novation’s  spread  (Augliere,  1994,  p.  3).  In  addition,  while  researchers  and  practitioners  have 
generally  come  to  expect  variance  between  management  and  technical  perspectives  on  the 
value  of  a  technology,  the  differences  we  see  here  at  the  level  of  adoption  of  technical  person¬ 
nel  are  noteworthy.  Such  differences  are  another  indicator  that  risk  reduction,  uncertainty  re¬ 
duction,  and  perceptions  on  adoption  and  implementation  are  more  complex  than  current 
theories  of  diffusion  and  transfer  would  have  us  understand. 

Diffusion  is  concerned  with  technology  spread,  with  the  movement  of  technologies  through  a 
consumer  population.  Thus,  research  has  focused  on  broad  adoption.  More  recently,  some  at¬ 
tention  has  turned  to  descriptions  of  the  technology  “as  it  is  experienced”  [Augliere,  1994]  and 
to  technology  incorporation  or  infusion.  Zmud  &  Apple  [1992]  observe  that  “the  incorporation 
of  many,  if  not  most,  innovations  follows  a  sequence  of  configurations  across  discrete  levels 
of  use,  with  advanced  incorporation  enabling  the  deeper  and  more  comprehensive  embedding 
of  an  innovation  within  an  organization’s  operational  and/or  managerial  work  systems.  It  is  this 
elaborated  use  that  we  connote  as  the  infusion  of  an  innovation”  (p.  1 50;  italics  Zmud  &  Apple). 

The  concept  of  infusion  is  helpful  in  understanding  the  processes  of  adoption  and  implemen¬ 
tation  of  RMA  at  ComCo,  Woodville.  For  example,  we  have  seen  that  the  granularity  of  per¬ 
ceptions  of  RMA  (from  300,000  to  30,000  feet)  relates  to  levels  of  use — a  topic  that  will  also 
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be  relevant  in  Section  5.5  on  technology  attributes.  In  addition,  the  idea  of  infusion  under¬ 
scores  the  need  to  see  innovation  decision  as  a  lengthy,  labor-intensive  process.  Manage¬ 
ment  sponsorship  and  the  user’s  exposure  to  a  technology  occur  through  time,  not  as  a  single 
transaction.  Support  for  an  innovation  and  the  users’  commitment  evolve  as  individuals  within 
an  organization  reference  each  others’  opinions.  TK,  a  senior  software  engineer,  remarked: 
“Convincing  people  to  use  RMA  on  [the  new  avionics  project]  was  especially  easier  after  the 
helicopter  project.”  His  colleague  (BH)  notes  that  even  though  “a  previous  program  proposal 
to  use  RMA  did  not  win,  they  had  already  decided  to  use  RMA  on  [the  new  avionics  project].” 

With  the  adoption  of  RMA,  we  saw  multiple  (sometimes  overlapping)  levels  of  sponsorship. 
The  senior-level  manager  (CK)  was  the  official  sponsor,  but  others  served  as  advocates,  in¬ 
cluding  the  champion,  the  change  agent,  the  manager  of  the  advanced  technical  solutions 
group,  and  the  distinguished  software  engineer.  As  each  of  these  individuals  came  to  see  val¬ 
ue  in  RMA,  there  was  more  reason  for  others  to  come  “on  board.”  One  engineer,  GP,  whose 
office  was  two  doors  down  from  the  change  agent’s,  observed:  “RMA  had  a  good  salesman. 
[The  change  agent]  DV  was  very  enthusiastic  and  dedicated  to  making  it  work.”  The  engineer 
added  that  the  salesman-change  agent,  DV,  had  a  cost  center  for  charging  work  related  to  the 
application  of  RMA.  “If  DV  wasn’t  two  doors  down,  we  wouldn’t  have  used  it.  [It]  also  helped 
that  DV  came  with  dollars.”  Proximity,  funding,  and  sales  reinforced  the  innovation-decision 
process.  The  senior  software  engineer  (TK)  commented  on  the  reputation  of  the  champion. 
When  we  asked  him  (TK)  when  he  had  realized  that  RMA  was  relevant  to  how  he  did  his  work, 
he  referred  to  a  project  that  the  champion  had  consulted  on,  and  he  said,  “Anything  that  DL 
[the  champion]  advocates  looks  good  to  the  whole  world.”  TK  was  “convinced  that  the  ap¬ 
proach  was  viable”  on  the  basis  of  the  earlier  project  and  the  champion’s  support  for  the  tech¬ 
nology. 

While  these  individuals  referenced  one  another,  another  dynamic  related  to  advocacy  was 
also  at  work.  This  concerns  the  dual  ladder  related  to  business  and  technical  Issues.  RB,  soft¬ 
ware  development  manager  (OCR),  indicated  that  he  would  “advocate  but  not  dictate  use”  of 
a  technology.  Although  current  theories  of  diffusion  wash  out  distinctions  between  advocacy 
and  mandate,  these  cultural  imperatives  represent  more  than  nuance:  diffusion  in  the  village, 
university,  or  business  setting  are  not  the  same,  in  each  of  these  environments,  exigency,  cul¬ 
ture,  and  time  play  a  role  in  the  adoption  and  implementation  of  new  technology.  The  innova¬ 
tion-decision  process,  as  experienced  by  the  individuals  we  interviewed  at  ComCo,  spanned 
eight  years,  from  1982  until  1990.  Table  2  summarizes  the  following  information:  interviewee, 
source  of  influence,  and  time  of  initial  exposure. 
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Table  2:  Exposure  To  RMA  Technology  by  Year 


1982-83 

Distinguished  Senior  Engineer  and  Project  Manager  (PK),  via  champion  (DL) 

1985-86 

Senior  Software  Engineer  (TK),  via  champion  (DL) 

1986-87 

Manager  Advanced  Technical  Solutions  Group  (LH),  via  champion  (DL) 

1987 

Software  Engineer  (BH),  via  champion  (DL) 

1987-88 

Manager  Avionics  Software  Development  (AMB),  via  Manager  Technicai  Research 
Group 

1987-88 

Manager  Software  Development  (OCR)  (RB),  via  change  agent  (DV) 

1989 

Software  Engineer  (SN),  via  change  agent  (DV)  /  public  tutoriai 

1990 

Software  Engineer  (JO),  via  public  tutorial 

1990 

Software  Engineer  (GP),  via  change  agent  (DV) 

The  innovation-decision  process  varied  from  person  to  person,  although  we  did  see  patterns 
in  support  and  commitment.  Proximity,  funding,  and  advocacy  were  influential.  At  ComCo, 
Woodville,  there  is  also  precedent  for  innovation:  the  avionics  software  manager  (AMB)  told 
us  that  she  tries  “to  insert  at  least  one  new  technology  in  each  project:  object  orientation,  risk, 
rate  monotonic  scheduling,  multiprocessing,  Ada.” 

As  suggested,  the  timing  and  circumstances  of  an  individual’s  adoption  and  use  of  the  tech¬ 
nology  were  tied  to  that  person’s  perception  of  the  technology,  specifically  its  attributes  and 
the  degree  of  information  or  experience  that  he  or  she  needed  to  solve  the  technical  problem. 
The  following  section  on  attributes  of  innovation  touches  on  factors  related  to  innovation  deci¬ 
sion. 


5.5  Attributes  of  Innovation 

The  interview  schedule  was  designed  to  capture  memorable  events  in  the  individuals’  pro¬ 
cesses  of  adoption  and  implementation — ^their  exposure  to  the  technology  and  perceptions 
about  its  use.  Our  goal  was  not  to  focus  specifically  on  attributes  of  the  technology  and  yet, 
indirectly,  many  of  the  questions  we  asked  called  up  issues  relating  to  relative  advantage, 
compatibility,  complexity,  trialability,  and  observability. 

The  following  is  illustrative.  The  question  we  asked,  “When  did  you  realize  that  RMA  was  rel¬ 
evant  to  your  work  and  how  did  you  know  it  was  relevant?”  suggested  issues  related  to  relative 
advantage.  Similarly,  the  question,  “Were  you  able  to  observe  how  RMA  was  helpful  to  oth¬ 
ers?”  called  up  the  matter  of  observability.  On  occasion,  we  asked  a  question  that  we  thought 
related  to  one  attribute,  and  we  received  information  more  closely  associated  to  another  at¬ 
tribute.  For  example,  when  we  asked  the  software  development  manager,  RB,  (OCR  project) 
about  how  easy  or  hard  it  was  to  use  the  technology  (associated  with  complexity  and  “ease” 
of  implementation),  he  commented  on  his  definition  of  the  technology  and  perception  of  its  rel¬ 
evance.  His  remarks  were  more  closely  related  to  relative  advantage  than  to  complexity.  This 
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blurring  with  respect  to  technology  attributes  underscores  a  critical  dilemma,  namely  their  sup¬ 
posed  integrity  and  stability. 

Table  3  offers  a  summary  of  key  attributes  of  innovations  and  their  definitions.  In  the  discus¬ 
sion  that  follows,  we  concentrate  on  the  five  attributes  discussed  in  Rogers  [1 983]  (first  five 
rows  in  the  table);  however,  the  table  also  includes  the  set  of  ten  attributes  covered  in  Tornatz- 
ky  &  Klein  [1982].35 


Table  3:  Attributes  of  Innovations 


Name 

Definition 

Relative  advantage 

Degree  to  which  an  innovation  is  perceived  as  being  better  than  the  idea  it 
supersedes  [Rogers,  1 983] 

Compatibility 

Degree  to  which  an  innovation  is  perceived  as  consistent  with  the  existing 
values,  past  experiences,  and  needs  of  potential  adopters  [Rogers,  1983] 

Complexity 

Degree  to  which  an  innovation  is  perceived  as  relatively  difficult  to  under¬ 
stand  and  use  [Rogers,  1983] 

Trialability 

Degree  to  which  an  innovation  can  be  experimented  with  on  a  limited  basis 
[Rogers,  1983] 

Observability 

Degree  to  which  the  results  of  an  innovation  are  visible  to  others  [Rogers, 
1983] 

Cost 

Cost  of  an  innovation  assumed  to  be  negatively  related  to  the  adoption  and 
implementation  of  an  innovation  [Tornatzky  &  Klein,  1 982] 

Communicability 

Degree  to  which  aspects  of  an  innovation  may  be  conveyed  to  others  [Roth¬ 
man,  1974] 

Divisibility 

Extent  to  which  an  innovation  can  be  tried  on  a  small  scale  before  adoption 
[Fiiegel,  Kivlin  &  Sekhon,  1968] 

Profitability 

Level  of  profit  to  be  gained  from  adoption  of  the  innovation  [Tornatzky  & 
Klein,  1982] 

Social  approval 

The  status  gained  in  one’s  reference  group,  a  “nonfinancial  aspect  of  re¬ 
ward”  [Fiiegel,  Kivlin  &  Sekhon,  1968] 

A  number  of  researchers  have  treated  the  notion  of  technology  attributes  [Downs  &  Mohr, 
1976;  Fichman  &  Kemerer,  1993;  Fiiegel,  Kivlin  &  Sekhon,  1968;  Rogers,  1983;  Rothman, 
1974;  Tornatzky  &  Klein,  1982].  Initially,  Downs  &  Mohr  [1976]  distinguished  between  primary 
and  secondary  attributes,  where  primary  attributes  represented  “objective”  features  or  charac¬ 
teristics  such  as  size  or  cost  of  the  technology;  on  the  other  hand,  secondary  attributes  were 


Tornatzky  &  Klein  [1987]  note  that  a  total  of  thirty  different  characteristics  were  studied  in  the  articles  that  they 
reviewed.  They  remark  that  “while  the  identification  of  ‘new’  innovation  characteristics  (e.g.,  risk  and  impact  on 
work  relationships)  may  be  useful,  there  is  a  real  need  to  determine  the  empirical  independence  of  these  charac¬ 
teristics  and  to  eliminate  redundant  characteristics"  (p.  41 ). 
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subjective  and  perceptually  based,  including  relative  advantage,  complexity,  etc.  Tornatzky  & 
Klein  [1 982]  argued  that  while  supposed 

primary  attributes  of  innovations  can  be  measured  “objectively,”  the  meaning  of 
the  objective  measure  of  the  characteristic  is  subjective,  that  is,  in  the  mind  of 
the  perceiver.  Thus,  while  an  innovation  may  cost  a  fixed  amount  (and  cost  is 
a  so-called  primary  attribute),  the  cost  of  the  innovation  is  evaluated  by  the 
potential  adopter  relative  to  his  or  her  financial  resources.  The  Innovation’s  cost 
may  seem  expensive  to  one,  exorbitant  to  another.  In  this  sense,  there  can  be 
no  primary  attribute  of  an  innovation.  Perceptions  are  always  evaluated  in 
reference  to  some  internalized  system  of  values  or  cognitive  framework;  the 
result  is  a  subjective  rating  of  the  “fact”  (e.g.,  size,  cost,  etc.)  (p.  28). 

Rogers  [1983]  also  ties  the  attributes  of  innovation  to  perceived  use.  He  suggests  that  these 
characteristics  by  which  an  innovation  can  be  described  illustrate  “how  individuals’  percep¬ 
tions  of  these  characteristics  predict  their  rate  of  adoption”  (p.  210). 

The  link  between  technology  attributes  and  the  perceived  benefits  of  use  is  critical.  Nonethe¬ 
less,  present  critiques  only  minimally  attend  to  variance  within  attributes  and  rarely  contend 
with  overlap  and  variance  between  characteristics.  The  overriding  assumption  is  that  these  at¬ 
tributes  are  discrete  and  stable.  This,  however,  does  not  appear  to  be  the  case.  Perceived  dif¬ 
ferences  exist  within  and  between  attributes.  For  instance,  in  the  study  of  RMA,  we  expected 
that  the  interviewees  would  have  different  perceptions  of  trialability  and  that  the  attribute  would 
not  be  perceived  as  absolute  or  unitary.  However,  we  were  more  surprised  to  see  blurring  be¬ 
tween  attributes,  as,  for  example,  when  one  person  viewed  the  opportunity  to  see  a  demon¬ 
stration  of  RMA  (observability)  as  a  trial  (trialability).  Understanding  the  dynamics  of  adopting 
and  implementing  new  technologies  requires  that  we  investigate  issues  surrounding  attribute 
definition  and  degree  of  variation:  what  constitutes  a  trial  (rather  than,  say,  an  observation)  as 
well  as  the  range  of  perspectives  on  trialability.®®  We  might  describe  this  as  a  necessary  shift 
in  orientation — away  from  characteristics  thought  to  reside  in  an  innovation — ^and  toward  per¬ 
ceptions  of  use;  in  other  words,  as  a  move  away  from  conventional  attributes  and  toward  the 
more  suggestive  concept  of  attribution.  Opening  such  a  dialogue  is  the  purpose  of  the  present 
discussion. 

In  the  following,  we  identify  Rogers’  key  attributes  of  innovation  and  discuss  the  interviewees’ 
comments  relating  to  these  attributes.  Only  one  of  the  interviewees  did  not  discuss  specific 
attributes:  LH,  the  manager  of  the  advanced  technical  solutions  group,  explained  her  ap¬ 
proach  to  introducing  new  technologies.  Our  conversation  with  her  took  a  more  free-ranging 

Some  researchers  do  not  find  the  notion  of  technoiogy  attributes  problematic.  Fichman  &  Kemerer  [1 983]  ob¬ 
serve  that  “although  Rogers’  synthesis  is  based  mostly  on  studies  of  adoptions  by  individuals  (e.g.,  of  consumer 
goods),  Van  de  Ven  and  others  have  argued  that  innovation  attributes  also  play  an  important  role  in  adoptions  by 
organizations...The  explanations  for  the  relative  advantage,  compatibility,  and  complexity  attributes  are  straight- 
fonvard  enough:  organizations  are  more  likely  to  be  willing  and  able  to  adopt  innovations  that  offer  clear  advan¬ 
tages,  that  do  not  drastically  interfere  with  existing  practices,  and  that  are  easier  to  understand.  Trialability  and 
observability  are  both  related  to  risk.  Adopters  look  unfavorably  on  adoptions  that  are  difficult  to  put  through  a  trial 
period  or  whose  benefits  are  difficult  to  see  or  describe.  These  characteristics  increase  the  uncertainty  about  the 
innovation’s  true  value”  (p.  9). 
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tack,  since  given  her  role  as  manager  of  the  advanced  technical  solutions  group,  she  did  not 
focus  exclusively  on  the  adoption  and  implementation  of  RMA. 

5.5.1  Relative  Advantage 

Relative  advantage  is  “the  degree  to  which  a  new  idea  is  perceived  to  be  better  than  an  exist¬ 
ing  practice.”  The  attribute  is  also  an  indicator  of  The  strength  of  the  reward  or  punishment  re¬ 
sulting  from  the  adoption  of  an  innovation”  (Rogers,  1983,  p.  217).  Advantage  may  be  borne 
out  in  terms  of  business  and  technical  goals  and  decisions  (for  example,  with  respect  to  a  dual 
ladder  such  as  the  one  described  at  ComCo)  and  may  translate  into  corresponding,  some¬ 
times  overlapping,  business  and  technical  advantages. 

As  we  might  expect,  relative  advantage  is  itself  relative  or  variable:  one  may  perceive  all, 
some,  or  none  of  the  advantages  that  others  might  associate  with  a  technology.  The  advan¬ 
tages  and  disadvantages  perceived  by  a  team  that  has  developed  a  technology  are  no  more 
correct  or  significant  than  the  perceptions  of  others.  In  fact,  if  such  a  team  was  focused  on 
technology  use,  they  would  more  likely  be  interested  in  the  responses  of  users  (standing  in  for 
customers)  than  in  their  own  perceptions.  With  respect  to  RMA,  we  saw  that  one  software  de¬ 
velopment  manager,  RB,  (OCR  project),  perceived  some  but  not  all  of  the  advantages  enu¬ 
merated  by  others.  When  we  asked  him  about  how  easy  or  difficult  it  was  to  use  RMA 
(information  related  to  complexity  and  its  ease  of  use),  he  said,  ‘The  hardest  part  was  probably 
doing  the  design  of  the  software;  it  has  nothing  to  do  with  RMA.”  This  remark,  when  corrobo¬ 
rated  by  our  technical  informant,  led  us  to  speculate  that  RB  did  not  perceive  that  RMA  was  of 
value  in  design.  Rather,  he  saw  RMA  as  an  analysis  tool.  He  indicated  that  one  should  analyze 
early  to  solve  timing  problems;  however,  he  did  not  see  RMA  as  a  design  tool.  In  terms  of  rel¬ 
ative  advantage,  RB’s  observation  of  RMA  did  not  include  a  perception  that  RMA  could  yield 
prescriptions  and  that  this  prescriptive  aspect  was  relevant  to  seeing  its  place  in  design. 

More  generally,  RB  discussed  the  relative  advantage  of  RMA.  He  said,  “I’m  impatient  that  it’s 
not  getting  implemented  faster.  I  think  it’s  a  key  technology.  I’m  part  of  the  problem  though  be¬ 
cause  I’m  not  mandating  it.  As  soon  as  I  dictate  technical  issues.  I’m  not  managing.”  As  we 
observed  in  the  earlier  discussion  on  the  innovation-decision  process,  RB  was  sensitive  to  the 
tension  between  dictating  and  advocating  the  use  of  the  technology. 

For  GP,  software  engineer,  the  deciding  factor  was  the  agent  for  the  technology.  When  we 
asked  GP  about  how  RMA  was  relevant  to  his  work,  he  said,  “I’m  not  sure  it  was  relevant.  We 
went  along  with  [the  change  agent,  DV]  because  we  were  one  of  the  first  Ada  programs.  DV’s 
model  sounded  like  it  would  give  us  insight  into  tasking  and  priorities.  After  the  fact,  it  was  help¬ 
ful,  but  I  don’t  think  our  program  fit  the  model.  We  didn’t  have  severe  timing  constraints.”  With 
respect  to  the  question  of  “fit,”  our  informant  observed  that  at  that  time,  RMA  technology,  in¬ 
dependent  of  an  expert  consultant,  may  not  have  been  sufficiently  mature  to  bridge  the  gap 
between  GP’s  knowledge  of  how  to  apply  RMA  and  his  requirements  for  RMA  (his  system  was 
event-driven).  In  Section  6,  Implications,  we  consider  the  relationship  between  technology  ma¬ 
turity  and  the  concept  of  the  whole  product. 


CMU/SEI-93-TR-030 


45 


Even  though  GP  perceived  a  limited  fit,  he  was  still  positive  about  ongoing  use  of  RMA.  When 
we  asked  him  if  he  would  continue  to  use  RMA,  he  said,  “Absolutely.  Would  definitely  use  it  if 
I  was  working  on  a  new  program.  I  think  it’s  a  very  useful  tool  for  understanding  how  you  will 
meet  your  timing  constraints.  I  hope  the  new  avionics  program  would  use  it...” 

SN,  another  software  engineer  and  colleague  of  GP,  observed  that  he  had  difficulty  trying  to 
extrapolate  the  model  from  periodic  to  aperiodic  tasks.  He  noted  that  the  tutorial  made  it  seem 
easy,  but  the  real  world  was  different.  SN  stated  that  “since  the  [air  flight  simulator]  program 
is  not  traditional  real  time,  initially,  it’s  hard  to  apply  the  theory  to  the  program.  We  couldn’t  find 
periodic  tasks;  we  worked  with  DV  [the  change  agent].”  SN’s  perception  of  relative  and  limited 
advantage  resembied  that  of  GP  and  was  also  tied  to  the  immaturity  of  the  technology  and 
the  missing  tools,  training,  and  materials  that  would  have  more  readily  enabled  engineers  to 
translate  RMA  theory  to  practice.  Our  informant  also  considered  this  to  be  so.  In  his  terms, 
these  individuals  were  responding  to  a  gap  in  the  technology  that  still  remained  to  be  closed 
at  that  time.  However,  the  informant  observed  that  “they  were  looking  for  the  tool  to  fit  the  prob¬ 
lem,  and  they  could  have  redefined  the  problem  to  fit  the  tool.” 

When  we  asked  PK,  distinguished  engineer  and  manager  of  the  Al  system  project,  whether 
RMA  helped  him  to  do  things  better  than  he’d  been  able  to  before,  he  said,  ‘Without  RMA  we’d 
be  struggling  with  ad  hoc  problems,  everything  we’ve  struggled  with  before.  We’re  getting  at 
the  procedural  issues,  and  the  reason  for  making  decisions.”  Later,  we  asked  him  if  he  would 
continue  to  use  RMA.  He  replied,  “DL  [RMA’s  champion]  has  shown  enough  horror  stories  that 
I  would  not  design  a  system  that  would  not  be  programmed  re:  RMA.”  At  the  close  of  the  in¬ 
terview,  he  mentioned  that  the  long-time  initiating  sponsor  (CK),  “the  czar  of  software  land  at 
ComCo,”  had  moved  to  another  site  but  he  (this  engineer)  could  not  conceive  of  ComCo, 
Woodville’s  “forgetting  the  formula.” 

5.5.2  Compatibility 

Compatibility  is  defined  as  the 

degree  to  which  an  innovation  is  perceived  as  consistent  with  existing  values, 
past  experiences,  and  needs  of  potential  adopters.  An  idea  that  is  more 
compatible  is  less  uncertain  to  the  potential  adopter.  An  innovation  can  be 
compatible  or  incompatible  (1)  with  sociocultural  values  and  beliefs,  (2)  with 
previously  introduced  ideas,  or  (3)  with  client  needs  for  innovations  (Rogers, 

1983,  p.  223). 

Typically,  in  the  areas  of  computer  science  and  software  engineering,  “compatibility”  is  asso¬ 
ciated  with  methodological  incompatibilities  or  with  platforms:  hardware,  software,  or  proto¬ 
cols.  However,  an  innovation’s  perceived  compatibility  also  relates  to  an  adopter’s  values, 
experiences,  and  needs.  In  the  discussion  of  relative  advantage,  we  noted  references  to  com¬ 
patibility  and  incompatibility.  Sometimes  a  perception  took  the  form  of  a  connection  or  a  lack 
of  association;  for  example,  RB,  one  of  the  software  development  managers,  did  not  associate 
RMA  with  design.  GP,  software  engineer,  said  that  he  went  along  with  the  change  agent’s 
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mode!,  but  he  wasn’t  sure  about  RMA’s  relevance:  he  didn’t  associate  the  technology  with  the 
event-driven  system  he  was  building.  In  each  of  these  instances,  there  was  a  lack  of  connec¬ 
tion  or  association,  if  not  an  outright  incompatibility. 

We  asked  the  interviewees  about  how  well  RMA  fit  in  with  how  they  did  their  work,  and  as  a 
follow-on  question,  whether  RMA  was  perceived  as  an  added  requirement.  RB,  software  de¬ 
velopment  manager  (OCR  project),  said  “It  fits  in  well  with  how  they  want  to  do  their  work.” 
“Yes,”  he  added,  “they  see  it  as  an  added  requirement.” 

Our  informant  speculated  that  these  individuals  were  perceiving  RMA  to  be  an  added  require¬ 
ment  and  not  a  savings  of  future  effort  or  future  integration  costs.  He  remarked,  “They  don’t 
see  timing  as  the  root  cause.” 

The  distinguished  senior  engineer  and  project  manager  for  the  Al  system  project  stated  that 
RMA  is  “fundamental  [to  how  we  do  our  work],  it’s  one  of  the  reasons  we  got  the  contract.” 

5.5.3  Complexity 

Complexity  is  “the  degree  to  which  an  innovation  is  perceived  as  relatively  difficult  to  under¬ 
stand  and  use.  Any  new  idea  may  be  classified  on  the  complexity-simplicity  continuum.  Some 
innovations  are  clear  in  their  meaning  to  potential  adopters  while  others  are  not”  (Rogers, 
1983,  p.  231). 

Rogers  suggests  the  following  generalization:  “The  complexity  of  an  innovation,  as  perceived 
by  members  of  a  social  system,  is  negatively  related  to  its  rate  of  adoption”  (Rogers,  1983,  p. 
231).  We  maintain  that  this  interpretation  is  too  limited  and  simplistic.  Complexity  must  be  un¬ 
derstood  in  terms  of  the  user’s  intent  and  expertise.  With  respect  to  the  adoption  of  RMA,  it  is 
critical  to  stress  the  domain  knowledge  of  the  users.  RMA  is  not  a  general-purpose  technology; 
hence,  it  is  largely  used  by  a  specialist  population  with  expertise  in  real-time  systems,  such  as 
we  saw  in  the  population  at  ComCo. 

Product  complexity  is  not  unidimensional.  There  are  different  types  of  complexity.  Technical 
complexity  refers  to  the  extent  to  which  something  may  be  hard  to  learn.  A  technology  or  effort 
may  also  be  complex  with  respect  to  its  impact  on  many  parts  of  an  organization.  Thus,  the 
attribute  of  complexity  straddles  issues  related  to 

•  The  purpose  of  the  user. 

•  His  or  her  prior  knowledge  and  expertise. 

•  Levels  of  use. 

•  Ease  of  implementation. 
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On  the  surface,  complexity  may  appear  to  be  obvious,  related  to  the  “objective”  or  operational 
features  of  an  innovation;  however,  perceived  complexity  may  be  a  highly  individualized  ratio 
based  on  the  technology  features  and  user  characteristics  identified  above.  Tornatzky  &  Klein 
[1982]  raise  similar  questions  about  this  attribute.  They  ask 

Does  “complexity”  refer  to  the  technical  knowledge  needed  to  use  an 
innovation?  To  the  impact  of  the  innovation  on  existing  work  relations?  To  the 
innovation’s  physical  appearance?  A  useful  approach  to  answering  these 
questions  might  involve  examining  the  statistical  relationship  between 
perceptual  and  objective  descriptions  of  innovations”  (p.  42). 

In  the  discussion  of  relative  advantage,  we  recall  that  one  of  the  software  engineers,  SN,  point¬ 
ed  out  that  the  RMA  tutorial  made  extrapolating  the  model  (from  periodic  to  aperiodic  tasks) 
seem  “easy”  but  that  the  effort  was  more  difficult  in  the  real  world.  It  was  “hard  to  apply  the 
theory  to  the  [air  flight  simulator]  program.”  This  simple  remark  illustrates  the  problematic  na¬ 
ture  of  the  attributes  in  general  and,  specifically,  complexity.  Where  does  relative  advantage 
leave  off  and  complexity  begin?  In  terms  of  complexity,  is  this  task  “easy,"  “hard,”  or  both? 
Which  use  is  primary:  the  “easier,”  more  theoretical  representation  in  the  tutorial  or  the  “hard¬ 
er,”  real-world  application?  As  noted,  technology  attributes  appear  straightforward;  however, 
closer  examination  reveals  that  the  characteristics  of  innovation  constitute  a  ball  of  tangled 
concepts  that  it  is  difficult  to  untangle. 

5.5.4  Trialability 

Trialability  is  “the  degree  to  which  an  innovation  may  be  experimented  with  on  a  limited  basis. 
New  ideas  that  can  be  tried  on  the  installment  plan  will  generally  be  adopted  more  rapidly  than 
innovations  that  are  not  divisible”  (Rogers,  1983,  p.  231).  In  addition,  Leonard-Barton  [1988b] 
treats  divisibility  as  “the  degree  to  which  an  innovation  can  be  partitioned  to  allow  trial  adop¬ 
tion”  (p.  613).  She  goes  on  to  identify  two  types  of  divisibility: 

(1)  modularization,  the  division  of  a  technology  into  stages  or  segments,  each 
of  which  delivers  some  benefits  upon  implementation,  even  if  no  further 
segments  are  adopted^^  [and]  (2)  individualization,  the  potential  for  beneficial 
use  of  a  technology  for  individual  output  by  some  organizational  members 
independent  of  the  innovation  responses  of  others  engaged  in  the  same  task 
(e.g.,  the  use  of  computer  work  stations  by  some  secretaries,  or  some 
engineers,  or  some  draftsmen)  (p.  613). 

Trialability  and  divisibility  are  not  one  and  the  same;  modularization,  as  Leonard-Barton  de¬ 
fines  it,  most  closely  resembles  incremental  use.  Trialability  is  a  multifaceted  characteristic, 
one  we  only  begin  to  discuss  here. 


On  the  topic  of  incremental  use,  our  technical  informant  stressed  that  to  some  extent,  at  the  smallest  level,  a 
principle  could  be  useful:  one  as  simple  as  “Things  that  run  faster  should  get  priority.”  However,  RMA  could  be 
applied  to  the  level  necessary  to  suit  a  person’s  purpose  to  see  the  benefit.  This  extension  of  use  is  possible  be¬ 
cause  RMA  is  based  on  mathematical  principles. 
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With  respect  to  RMA,  we  saw  many  types  of  trials — variance  within  the  attribute  of  trialability — 
and  evidence  of  blurring  between  trialability  and  other  attributes.  The  first  of  the  two  following 
examples  illustrates  differences  within  trialability;  the  second  suggests  overlap  between  trial- 
ability  and  observability.  PK,  the  distinguished  senior  engineer  and  project  manager,  men¬ 
tioned  two  levels  of  trial:  proof  and  activity.  Moreover,  he  linked  relevance  judgments  to 
trialability.  When  we  asked  him  about  when  he  realized  RMA  was  relevant,  he  said,  “right  off 
the  bat  because  what  we  deal  with  is  real  time  in  nature.  I  read  the  paper  [Liu  &  Layland,  1 973] 
and  went  through  the  proof  once.”  Shortly  after,  we  asked  him  if  he  tried  out  RMA.  He  said, 
“We  broke  the  scheduling  tool  [they  tried  to  use  DV’s  university  prototype  tool]  and  we’re  trying 
it  out  now.  Given  an  understanding  of  the  technology  and  having  gone  through  the  proof,  I’m 
really  trying  it  out  now.” 

TK’s  response  (senior  software  engineer)  was  quite  different.  When  we  asked  him  about 
whether  or  not  he  tried  out  RMA,  he  said,  “Yes,  [the  helicopter  project]  served  in  part  as  a  trial. 
[The  project]  was  a  multiprocessor.  The  program  had  lots  of  problems  and  they  were  always 
looking  for  ways  to  assess  risk  in  assuming  maintenance.  The  results  are  not  in  but  they  did 
determine  risks  based  on  that  analysis.”  For  TK,  trialability  is  embodied  in  the  nature  of  anal¬ 
ogizing:  he  is  not  picturing  trial  as  pilot  use.  Instead,  his  remarks  suggest  that  trial  use  occurs 
by  individual  engineers  who  pick  up  so  many  technologies  for  their  toolbox.  In  this  instance, 
there  is  a  noticeable  overlap  between  a  trial  and  an  observation. 

Our  technical  informant  suggested  that  TK’s  trial  was  at  a  high  level.  Not  surprisingly,  this 
matches  TK’s  interests  as  expressed  earlier.  We  recall,  for  example,  in  our  discussion  of  the 
innovation-decision  process,  that  two  of  the  engineers  on  the  avionics  system  upgrade  project 
“adopted”  RMA  technology  at  different  levels.  TK,  the  senior  software  engineer,  was  con¬ 
cerned  with  adopting  the  technology  and  with  associated  risks  at  the  highest  level,  at  “300,000 
feet.”  Our  informant  speculated  that  TK’s  (somewhat  junior)  colleague,  also  a  software  engi¬ 
neer  (BH),  was  operating  at  “30,000  feet.”  When  we  asked  this  engineer  if  RMA  helped  him  to 
do  things  better  than  he  had  before,  BH  said,  “Ideally,  but  it’s  early.  The  concepts  were  rela¬ 
tively  easy  to  grasp  in  class;  modeling  a  system  will  not  be  so  easy.” 

These  perspectives  associated  with  high  and  low  concerns  and  levels  of  trial,  including  proof 
and  activity,  suggest  that  trialability  is  more  multifaceted  than  common  thought  allows.  The 
high/low  distinction  should  not  be  reduced  to  making  a  slice  between  managerial  and  technical 
perspectives;  both  levels  of  concern  expressed  here  relate  to  technical  issues. 

Finally,  we  are  unable  to  comment  on  whether  the  change  agent’s  (DV’s)  demonstration 
served  as  a  trial  or  observation.  The  simple  existence  of  a  demo  may  have  been  persuasive 
enough  for  some;  however,  we  have  no  data  on  the  number  of  people  who  actually  went 
through  the  entire  demo. 
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5.5.5  Observability 

Observability  is  “the  degree  to  which  the  resuits  of  an  innovation  are  visible  to  others.  The  re¬ 
sults  of  some  ideas  are  easily  observed  and  communicated  to  others  whereas  some  innova¬ 
tions  are  difficult  to  describe  to  others.”  Rogers  [1983]  goes  on  to  note  that  a  technology  has 
two  components:  “(1 )  a  hardware  aspect  that  consists  of  the  tool  that  embodies  the  technology 
as  material  or  physical  objects,  and  (2)  a  software  aspect  that  consists  of  the  information  base 
for  the  tooi”  (p.  232).  He  suggests  that  the  software  component  of  an  innovation  is  less  visible; 
thus,  the  lesser  degree  of  observability  means  that  software  innovations  are  adopted  more 
slowiy  and  affect  people’s  work  in  subtler  ways.  Rogers’  distinctions  are  important;  however, 
we  will  see  shortly  that  understanding  technology  use  and  the  relationship  between  technolo¬ 
gies  and  whole  products  is  more  complex  than  distinctions  between  hardware  and  software 
aspects.  Similarly,  forms  of  observation  must  be  extended  beyond  seeing  a  thing  work;  forms 
of  observation  must  also  account  for  the  observed  behavior  of  peopie  as  well  as  the  time, 
space,  and  number  and  relationship  of  peopie  invoived  in  the  use  of  a  technology  and  its  tran¬ 
sition. 

When  we  asked  the  software  development  manager  (RB  of  the  OCR  project)  whether  he  was 
able  to  observe  how  RMA  was  helpful  to  others,  he  said,  “Initially,  no;  I  didn’t  see  its  usefulness 
early  on.”  He  went  on  to  add,  “We  did  not  apply  it  to  what  we  were  doing.  We  weren’t  doing  a 
real-time  application,  so  it  wasn’t  applied.”  Previously,  however,  when  we  asked  him  about  his 
decision  to  use  RMA,  he  referred  to  the  time  when  the  change  agent  (DV)  had  been  able  to 
work  with  them  and  they  had  sat  down  and  used  the  university  prototype  tool.  Some  overlap 
exists  here  between  observation  of  RMA  and  observation  of  the  usefulness  of  RMA.  This  may 
suggest  a  blur  between  observability  and  usefulness  (relative  advantage);  or  the  source  of  am¬ 
biguity  here  may  be  the  result  of  our  question,  which  touched  on  both  characteristics  at  the 
same  time. 

At  the  close  of  the  interview  with  the  avionics  software  development  manager,  AMB,  we  asked 
her  if  there  was  anything  else  she’d  like  to  talk  about.  She  responded,  “I’m  waiting  to  see  if  it 
[RMA]  will  go  from  theory  to  reality.  “Is  there  anything  that  would  help  you  more?”  we  inquired. 
“A  real  RMS  [rate  monotonic  scheduling]  tool  would  help  even  more  where  you  could  feed  it 
tests  and  it  would  pump  out  results.  We  are  using  that  more  primitive  tool  from  [the  university].” 

5.5.6  Summary  Remarks 

In  general,  the  interview  data  we  gathered  relating  to  technology  attributes,  especially  trialabil- 
ity  and  observability,  confirmed  that  technology  use  was  not  a  unidimensional  or  homoge¬ 
neous  practice.  We  discovered  noticeable  spread  in  how  and  when  technologies  were 
used — ^at  different  times  with  different  constraints  and  degrees  of  freedom.  Use  of  RMA  inciud- 
ed  troubleshooting,  analysis  of  an  existing  system,  and  design,  at  different  phases  of  the  soft¬ 
ware  development  life  cycle.  Several  individuals  with  experience  in  these  varied  kinds  of  use 
were  abie  to  extrapolate  about  how  RMA  might  be  used  not  to  solve  a  particular  problem  so 
much  as  to  predict  what  would  be  problematic.  There  seemed  to  be  a  preventative  aspect  to 
this  kind  of  use,  and  it  occurred  earlier  in  the  life  cycle. 
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PK  (distinguished  senior  engineer  and  project  manager)  used  RMA  in  a  manner  unprecedent¬ 
ed  and  unanticipated  by  RMA’s  deveiopers.  He  bypassed  consideration  of  normal  use;  he  had 
a  vision  for  something  bigger  and  more  important,  seeing  the  repercussions  of  appiying  RMA 
concepts  to  systems,  not  just  software.  For  PK,  in  true  innovator  styie,  the  technology  was  just 
a  point  of  departure.  In  his  remarks,  we  saw  the  range  of  his  application  of  RMA  and  his  more 
abstract  phiiosophical  perspective  on  the  “discipiine”  that  the  technoiogy  provided. 

The  Al  system  was  bid  in  1989,  started  in  1990.  RMA  is  being  used  with  respect 
to  scheduling  mechanisms,  designing  interrupt  handlers,  assigning  priorities  to 
the  rule-based  system.  These  things  are  often  aperiodic  but  we’d  iike  to  put 
some  kind  of  discipline  around  them.  We’re  just  in  the  process  of  bringing  up 
the  runtime  software,  assigning  priorities  and  then  we’li  use  [DV’s]  tool  set  to 
do  the  analysis.  RMA  has  been  designed  in  from  the  beginning.  Knowing  you’re 
going  to  do  the  analysis  informs  the  design. 

An  important  question  remains:  what  relationship  exists  between  the  decision  to  innovate,  the 
perceived  attributes,  and  the  maturity  of  the  technoiogy?  This  subject  serves  as  the  center- 
piece  in  the  impiications  discussion  that  foiiows. 
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6  Implications 


At  the  highest  level,  the  results  yielded  three  key  findings  that  have  implications  for  what  we 
identify  as  an  integrating  theme:  the  concept  of  the  whole  product  [Moore,  1991].  To  summa¬ 
rize. 


1 .  We  observed  that  existing  infrastructure,  including  DV’s  efforts  as  change 
agent  operating  at  the  site  level,  was  necessary  to  support  the  adoption  and 
implementation  of  RMA  at  ComCo. 

2.  The  innovative  culture,  in  conjunction  with  the  organization’s  infrastructure, 
compensated  for  missing  aspects  of  the  maturing  technology. 

3.  We  saw  that  a  critical  link  existed  between  technology  attributes  and 
perceptions  of  use,  and  that  technology  “use"  was  more  complex  than  current 
understanding  of  diffusion  theory  allows. 

These  findings  benefit  from  consideration  alongside  ideas  of  technology  and  product  maturity; 
thus,  the  whole  product  concept  is  a  useful  lens  through  which  to  view  ComCo’s  processes  of 
adoption  and  implementation  of  RMA. 

6.1  The  Concept  of  the  Whole  Product 

As  indicated,  RMA  was  relatively  more  mature  as  a  technology,  in  the  sense  that  it  was  no 
longer  evolving  rapidly,  than  as  a  product.  Geoffrey  Moore  [1991]  argues  that  majority  accep¬ 
tance  of  a  technology  is  contingent  upon  the  existence  of  a  whole  product:  the  core  technology 
and  the  availability  of  a  range  of  adjunct  products  and  services,  including  training  and  support, 
cables,  installation  and  debugging,  system  integration,  additional  hardware,  additional  soft¬ 
ware,  and  standards  and  procedures  (p.  1 1 5).  (See  Figure  6-1 .)  Moore  is  primarily  focused  on 
business  development,  on  helping  high-tech  companies  cross  a  “chasm”  from  a  small  custom 
or  early  market  to  a  mass  or  mainstream  market.  Nonetheless,  the  whole  product  concept  has 
application  for  understanding  technology  adoption  and  use,  since  a  large  part  of  what  makes 
a  business  successful  is  its  marketable  products. 

Typically,  vendors  are  focused  on  sales.  Our  focus  on  adoption  and  implementation  extends 
beyond  purchase  to  “use”  and  is  more  unconventional  in  the  product  development  arena. 
However,  the  perspective  of  use  is  relevant  and  timely.  Increasingly,  innovative  companies  are 
looking  beyond  product  sales  to  the  customer’s  experience  in  applying  and  incorporating  a 
technology.®®  In  part,  the  need  to  attend  to  technology  use  is  arising  out  of  the  process-inten¬ 
sive  nature  of  new  software  technologies.  More  significantly,  the  attention  that  vendors  and 
tool  builders  are  giving  to  adoption  and  implementation  processes  reveals  the  software  com¬ 
munity’s  growing  concern  with  technology  maturation,  with  making  necessary  links  between 
technology  development  and  transition. 


One  forward-looking  tool  builder  in  the  area  of  software  configuration  management  (SCM)  now  sells  what  it  calls 
“adoption  services”  packages.  These  packages  were  designed  to  help  clients  achieve  maximum  benefit  from  the 
implementation  of  the  SCM  tool  they  were  purchasing. 
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Whol©  products  are  the  embodiment  of  the  maturation  process.  They  consist  of  the  creation 
of  a  robust  technology  that  is  commercial  grade;  that  is,  the  technology  is  in  product  form,  has 
a  reasonable  user  Interface,  and  performs  reliably.  Related  products  and  services  such  as  hot¬ 
lines,  training,  consulting,  and  documentation  exist;  distribution  channels  have  been  estab¬ 
lished;  and  bundling  with  related  technologies  has  been  accomplished  through  value-added 
re-sellers  (VARs)  or  the  equivalent.  Based  on  these  distinctions,  we  hypothesize  that  a  “ma¬ 
jority”  adopter  population  [Rogers,  1983]  is  less  likely  to  succeed  with  the  introduction  of  an 
immature  technology — one  that  has  not  been  commercialized — because  of  their  intolerance 
for  missing  aspects  of  the  whole  product. 

By  contrast,  the  people  we  interviewed  at  ComCo  functioned  almost  as  co-developers;  they 
counterbalanced  the  immaturity  of  RMA  by  building  an  “in-house”  version  of  a  whole  product, 
one  tailored  for  internal  use.  Because  of  this  willingness  to  negotiate  gaps  or  missing  pieces 
in  the  emergent  technology,  we  see  ComCo  as  an  “early  adopter'’  population.  We  noted  earlier 
that  two  aspects  of  the  organization  were  key  in  making  compensation  for  immaturity  possible: 
infrastructure  and  innovative  culture.  However,  while  these  characteristics  may  signal  early 
adopter  tendencies,  a  qualification  must  be  made.  Classifying  how  individuals  take  up 
innovations  by  adopter  category  is  more  suggestive  than  definitive.  Similarly,  since 
organizations  frequently  display  multiple  traits,  population  profiles  should  not  be  endorsed 
wholesale.  For  instance,  an  organization  may  be  innovative  with  respect  to  its  R&D  portfolio 
and  cautious  with  respect  to  its  use  of  enabling  technologies  to  support  development.  Some 
organizations,  especially  small  ones,  may  be  hard  pressed  to  support  innovative  activities  on 
a// fronts;  and  large  organizations  like  ComCo  can  be  viewed  as  using  the  fruits  of  history  and 
profit  margins — its  infrastructure  and  deep  pockets — ^to  support  aggressive  innovation.  With 
these  caveats  in  mind,  we  say  that  ComCo’s  behavior  with  respect  to  RMA  revealed  an  early 
adopter  disposition — a  willingness  to  engage  in  joint  exploration  and  to  take  calculated  risk. 
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At  what  level  of  maturity,  then,  was  RMA?  Specific  information  about  the  status  of  the  technol¬ 
ogy  is  in  order.  The  interviewees  we  spoke  with  had  access  to  a  limited  set  of  products^®  and 
services  during  the  time  that  they  were  attempting  to  use  RMA.  Many  of  these  products  had 
been  extended  and  adapted  for  use  by  the  organization.  Several  SEI  technical  papers  de¬ 
scribed  RMA  theory  and  application  [Sha  &  Goodenough,  1990;  Sha,  Klein,  &  Goodenough, 
1991].  A  technical  tutorial  (developed  by  the  SEI)  had  been  adapted  by  ComCo  and  was 
taught  internally  as  a  two-day  seminar.  The  organization  had  aiso  funded  university  develop¬ 
ment  of  a  prototype  tool.  Demonstration  software  had  been  developed  in-house  and  was  used 
by  the  change  agent  (DV)  as  proof  of  the  practical  applicability  of  RMA.*^®  Thus,  the  change 
agent  had  acquired  not  only  theoretical  knowledge  but  significant  application  skills,  and  he  was 
positioned  to  help  others  who  expressed  interest.  Initially,  training  was  available  from  the 
change  agent  and  from  the  initiating  sponsor  (who  acted  as  an  advocate  for  RMA  across  mul¬ 
tiple  sites).  In  addition,  ComCo  had  developed  and  delivered  a  three-hour  technical  overview 
for  executives. 

This  collection  of  products  and  senrices  might  seem  to  imply  whole  product  maturity;  however, 
each  component,  other  than  the  technical  papers,  was  custom  developed  or  adapted  for  Com¬ 
Co  rather  than  supplied  by  a  commerciai  vendor.  The  individual  components  were  discrete 
and  had  not  been  designed  to  be  integrated  or  compatible.  In  fact,  while  interviewees  spoke 
highly  of  the  change  agent,  they  expressed  concern  that  only  one  very  limited  tool  was  avail¬ 
able,  and  they  indicated  eagerness  to  obtain  the  engineering  handbook  on  RMA  that  was  un¬ 
der  preparation  at  that  time  [Klein,  Ralya,  Poliak,  Obenza,  &  Gonzalez  Harbour,  1993].  They 
remarked  that  the  classroom  training  provided  “concepts  that  are  relatively  simple  to  grasp” 
but  that  “modeling  a  system  [is]  much  more  difficult,”  and  that  it  was  helpful  to  have  either  the 
champion  or  the  change  agent  “for  a  couple  of  weeks.”^^  Despite  these  difficulties,  application 
of  RMA  did  occur,  and  the  interviewees  agreed  that  RMA  was  an  important  technology  that 
should  be  used  whenever  possible.  Nonetheless,  ComCo’s  adaptation  and  enhancement  of 
the  SEI  based-products  and  services  were  critical  in  the  introduction  and  use  of  RMA  during 
the  period  spanning  1985-1990. 

To  summarize,  RMA  was  a  relatively  mature  technology  but  not  a  mature  whole  product.  We 
believe  that  features  of  the  organizational  infrastructure  already  described  and  the  attitudes 

These  “products”  are  not  products  in  the  usual  commercial  sense  of  being  packaged  and  sold.  Perhaps  it  is  most 
appropriate  to  view  them  as  elements  or  components  of  an  embryonic  “whole  product.” 

It  was  In  the  preparation  of  this  demonstration  software  that  the  change  agent  acquired  significant  expertise  in 
the  application  of  RMA. 

In  Section  5.5,  Attributes  of  Innovation,  we  referred  to  GP’s  comments  on  perceived  advantage  (see  pp.  45-46). 
When  we  asked  GP  about  how  RMA  was  relevant  to  his  work,  he  said,  “I’m  not  sure  it  was  relevant.  We  went 
along  with  [the  change  agent,  DV]  because  we  were  one  of  the  first  Ada  programs.  DV’s  model  sounded  like  it 
would  give  us  insight  into  tasking  and  priorities.  After  the  fact,  it  was  helpful,  but  I  don’t  think  our  program  fit  the 
model.  We  didn’t  have  severe  timing  constraints.”  We  recall  that  our  informant  observed  that,  at  that  time,  RMA 
technology  may  not  have  been  sufficiently  mature  to  bridge  the  gap  and  meet  GP’s  concerns  about  their  system, 
which  was  event-driven.  We  also  observed  that  SN,  another  software  engineer  and  colleague  of  GP,  had  difficulty 
trying  to  extrapolate  the  model  from  periodic  to  aperiodic  tasks.  He  noted  that  the  tutorial  made  it  seem  easy,  but 
the  real  world  was  different.  SN’s  perception  of  relative  and  limited  advantage  was  also  tied  to  the  immaturity  of 
the  technology — and  the  missing  tools,  training,  and  materials  that  would  have  more  readily  enabled  engineers 
to  translate  RMA  theory  to  practice.  Our  technical  informant  also  considered  this  to  be  so. 
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revealed  by  the  interviewees’  comments  offer  evidence  for  an  innovative  corporate  culture.  A 
culture  similar  to  this  appears  to  be  prerequisite  to  the  successful  adoption  and  implementation 
of  immature  technoiogy;  that  is,  technoiogy  that  has  not  been  fuiiy  developed  into  a  product. 
When  products  and  services  adjunct  to  a  technology  are  not  commercially  available,  an  orga¬ 
nization  with  a  culture  of  innovation  can  compensate,  as  was  the  case  with  this  organization. 
Moreover,  the  infrastructure  that  was  in  place  existed  to  handle  a  continuing  stream  of  new 
technologies,  thus  minimizing  the  need  to  make  special  arrangements  for  any  one  technology. 

In  the  interim,  RMA  continues  to  evolve  toward  becoming  a  whole  product.  A  second  RMA  Us¬ 
ers  Forum  has  been  held  since  these  interviews  were  conducted.  Presentiy,  two  commercial 
vendors  offer  training.  The  handbook  that  severai  interviewees  saw  as  necessary  to  fill  a  crit¬ 
ical  gap  was  published  in  1993.  In  addition,  aimost  all  of  the  interviewees  expressed  the  need 
for  a  tool  to  support  RMA;  now,  two  tool  builders  (who  attended  the  second  RMA  Forum)  are 
developing  commerciai  tools. 

In  effect,  what  the  large  organization  with  “early  adopter”  characteristics  was  able  to  create  in¬ 
ternally  is  gradually  becoming  available  in  the  commercial  marketplace.  The  existence  of  a 
tool,  which  seems  likely,  in  combination  with  these  new  products  and  services,  will  mark 
RMA’s  passage  to  a  mature  whole  product.  At  that  time,  we  suspect  that  the  range  of  organi¬ 
zations  able  to  use  the  technology  will  broaden.  Previously,  an  organization  without  a  culture 
of  innovation  or  the  infrastructure  of  the  kind  discussed  here,  or  without  the  willingness  and 
resources  to  build  infrastructure,  would  have  been  hard  pressed  to  successfully  introduce  and 
use  RMA. 
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6.2  Developers  of  Maturing  Technologies 

What  can  be  learned  from  the  RMA  case  study?  We  might  assume  that  the  lessons  and  im¬ 
plications  associated  with  the  study  would  be  most  relevant  to  individuals  who  work  to  pull  in¬ 
novations  “into”  their  organizations:  technology  receptors.  Often,  these  receptors  are 
members  of  software  engineering  process  groups  (SEPG)  or  advanced  technology  groups. 
They  scan  the  horizon  for  new  technologies  and,  downstream,  they  act  as  change  agents  in 
the  process  of  introduction.  Certainly,  the  study  has  implications  for  the  technology  receptor 
community.  However,  in  a  larger  sense,  the  agents  of  change  for  technology  maturation  in¬ 
clude  all  the  individuals  along  the  continuum  from  development  to  transition.  In  other  words, 
meaningful  lessons  for  development  often  come  not  from  development  alone,  but  from  use.  In 
the  same  spirit,  the  implications  of  this  study  on  adoption  and  implementation  and  the  findings 
related  to  the  theme  of  the  whole  product  have  significance  for  parties  on  both  sides  of  the 
push-pull  equation. 

In  the  following  subsections,  we  comment  briefly  on  implications  for  developers:  managers  of 
R&D,  including  funding  agents;  and  researchers.  We  offer  a  final  obsen/ation  on  the  contribu¬ 
tion  that  research,  especially  the  case  study,  makes  to  a  greater  understanding  of  technology 
transition. 

Key  issues  in  this  area  include 

•  Concurrent  technology  transition. 

•  Prototyping  of  the  process  of  technology  introduction. 

•  Creation  of  a  template  for  the  whole  product. 

If  we  see  mature  technology  as  readily  used  or  ready-to-use  technology,  then  we  must  define 
technology  maturation  as  a  combination  of  technology  development  and  technology  transition. 
Conventionally,  software  technology  transition  begins  after  development,  too  late  to  influence 
the  shape  of  the  technology  and  make  it  responsive  to  user  needs.  The  old  paradigm  pre¬ 
cludes  meaningful  interaction  between  developers  and  users. 

Leonard-Barton  [1 988a]  describes  a  process  of  “mutual  adaptation”  in  which  both  organization 
and  technology  must  be  adjusted  for  transition  to  be  considered  complete.  The  process  is 
based  largely  on  research  into  the  transition  of  complex  software  innovations  such  as  expert 
systems  and  manufacturing  systems.  The  research  suggests  that  those  doing  the  planning  for 
technology  transition  should  anticipate  changes  not  just  to  the  technology  (however  mature) 
but  to  organizational  processes  as  well.  Leonard-Barton  discusses  the  idea  of  reinvention  and 
considers  how  organizations  as  well  as  technologies  change  as  they  modify  and  add  value  to 
maturing  technologies. 

We  argue  that  the  concepts  of  mutual  adaptation  and  the  whole  product  can  be  extended  by 
the  principles  of  concurrent  engineering  (see  Figure  6-2),  and  thus  lead  to  an  improvement  of 
the  effort  and  time  it  takes  to  accomplish  software  technology  transition.  Moreover,  the  ap¬ 
proach  should  lead  to  improved  products,  since  use  of  these  principles  stresses  that  research. 
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new  product  development,  and  implementation  issues  and  tasks  are  worked  concurrently. 
When  this  occurs,  information  about  how  well  the  technology  is  working  in  context — ^that  is,  not 
just  information  about  how  the  technology  is  developing — can  be  obtained  immediately.  Two 
innovative  strategies  can  facilitate  concurrent  technology  transition  and  significantly  reduce 
the  length  of  time  required  for  creation  and  diffusion  of  a  mature  technology:  (1)  prototyping 
the  process  of  technology  introduction  and  (2)  creating  a  template  for  the  whole  product. 


Critical  information  related  to  the  process  of  introduction  for  a  technology  can  be  discovered 
and  “captured”  when  the  technology  is  in  use  at  an  early  adopter  or  pilot  site.  What  is  required 
for  the  discovery  of  this  process  is  attention — ^attention  to  the  thought  processes  and  behavior 
of  those  who  are  attempting  to  use  the  technology  in  question.  In  this  instance,  observing  the 
use  of  the  technology  might  involve  monitoring 

1 .  The  innovation-decision  process,  including  how  commitment  is  built  and  sus¬ 
tained. 

2.  Usability  with  respect  to  how  individuals  experience  the  technology,  since 
reliance  on  technology  attributes  is  insufficient. 
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3.  Users’  compensatory  strategies  for  coping  with  problematic  or  missing 
aspects  of  the  technology. 

4.  Adjunct  products  and  services,  whether  existing  or  new,  that  are  developed 
or  enhanced  to  support  in-house  use. 

If  the  technology  is  being  disseminated  or  “rolled  out”  to  other  parts  of  the  organization,  we  can 
also  attend  to  how  this  is  accomplished  by  examining  the  rollout  plan,  related  briefings  to  se¬ 
cure  buy-in  or  commitment,  and  other  artifacts  designed  to  support  the  use  of  the  technology, 
including  coaching,  documentation,  aids  for  job  performance,  etc. 

The  prototype  process  of  introduction  represents  one  component  of  what  is  necessary  to  en¬ 
sure  use  of  the  in-house  whole  product.  (The  equivalent  for  the  commercial  whole  product 
would  consist  of  a  defined  and  tested  process  of  adoption  and  implementation.'^^)  Essentially, 
here  we  are  able  to  extend  Moore’s  notion  of  the  whole  product  beyond  a  concern  with  pur¬ 
chase  to  address  usage.  The  question  driving  the  assembly  of  the  whole  product,  then,  be¬ 
comes:  what  essential  products  and  services  are  required  to  achieve  the  user’s  compelling 
reason  to  purchase  and  use  the  technology?  Elements  or  components  might  include  any  of 
those  identified  above,  including  training  and  support,  additional  hardware  and  software,  a 
prepared  technical  environment,  hotlines,  etc.  The  answer  to  this  question,  we  suggest,  can 
be  derived  from  technology  exploration.  Thus,  if  we  look  to  an  early  adopter  site  as  a  testbed, 
we  can  observe  how  a  population  attempts  to  use  an  immature  or  emergent  technology.  We 
can  see  how  and  where  users  expend  effort  to  identify,  develop,  and/or  customize  (where  pos¬ 
sible,  to  purchase)  those  whole-product  elements  that  ensure  use.  By  close  observation  and 
collaboration,  we  may  work  at  a  site  to  discover  and  capture  strategic  information  for  transition: 

1 .  A  prototype  process  of  introduction. 

2.  Requirements  and  specifications  for  the  in-house  whole  product — ^the  adjunct 
products  and  services  surrounding  the  core  technology. 

The  latter  information  offers  us  a  template  for  what  critical  components  must  exist  in  the  com¬ 
mercial-grade  whole  product. 

The  close  observation  that  we  advocate  may  be  impossible  or  inappropriate  in  some  circum¬ 
stances.  For  instances  in  which  collaboration  with  an  early  adopter  site  is  precluded,  develop¬ 
ers  and  practitioners  must,  nonetheless,  continue  to  reflect  on  their  transition  efforts  and 
activities.  They  must  find  efficient  ways  to  capture  this  know-how  so  that  lessons  can  be 
shared  with  others  through  experience  reports.  They  must  consider 

•  What  aspects  of  the  technology  maturation  process  are  important? 

•  How  best  can  they  be  described? 

•  To  whom  are  these  descriptions  relevant? 


The  perspective  we  are  taking  here  on  defined  processes  for  adoption  and  implementation  based  on  technology 
use  and  the  user’s  experience  is  new.  Some  basic  and/or  generic  work  has  been  done  in  this  area  in  conjunction 
with  software  process  improvement  initiatives;  however,  we  are  not  aware  of  other  substantive  explorations  aside 
from  our  own  pilot  efforts. 
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•  How  early  in  the  maturation  of  a  technology  can  a  transition  process  be 
captured  and  still  predict  later  transition  approaches? 

•  How  can  we  anticipate  the  needs  of  the  change  agents  who  must  introduce 
the  technology  under  consideration? 

These  are  difficult  questions,  requiring  more  than  generic  answers.  Developers  and  practitio¬ 
ners  may  want  to  turn  to  case  study  research  as  well  as  others  experience  reports  for  guid¬ 
ance  in  answering  these  questions. 

6.3  R&D  Managers  and  Funding  Agents 

If  transition  is  a  goal  early  in  the  development  of  a  technology,  then  concern  about  transition 
success  is  integral  to  the  development  effort.  While  the  need  for  a  detailed  vision  of  application 
may  strike  some  as  obvious,  many  technology  developers  are  unfamiliar  with  strategic  plan¬ 
ning  or  third-generation  R&D  management  [Roussel,  Saad,  &  Erikson,  1991].  Those  funding 
technology  development  within  their  own  organizations  or  in  external  organizations  such  as 
universities  appear  to  expect  that  the  technology  being  developed  will  automatically  be  used. 
While  advice  for  technologists  and  managers  on  processes  for  selecting  an  optimal  mix  of 
R&D  projects  is  available  (for  example,  Roussel,  Saad,  &  Erickson,  1991),  guidance  on  how 
to  attend  to  the  transfer  of  specific  types  of  technologies  that  these  projects  may  develop  is 
rare.  In  addition,  software  technologies  require  a  transition— not  just  a  binary  transfer— pro¬ 
cess,  and  a  process  not  just  from  R&D  to  product  development,  but  also  (as  we  have  been 
discussing)  from  product  suppliers  into  the  day-to-day  use  that  reflects  incorporation  [Zmud  & 
Apple,  1992]. 

In  Part  1  of  the  case  study,  we  observed  that  co-development  partnerships  and  distribution 
partnerships  were  necessary  to  ensure  the  transition  of  RMA.  We  also  speculated  that  the  SEI 
Rate  Monotonic  Analysis  for  Real-Time  Systems  (RMARTS)  Project  engaged  third-party  ven¬ 
dors  for  training  and  publication  late  in  the  technology  development  life  cycle.  In  hindsight, 
project  members  observed  that  partnerships  with  training  firms  and  tool  vendors  might  have 
been  worked  on  earlier  in  the  life  cycle.  We  cannot  say  to  what  extent  the  transition  of  the  tech¬ 
nology  would  have  been  accelerated  by  focusing  on  new  product  development  concurrently, 
alongside  technical  development  and  extension."^  However,  managers  and  funding  agents 
are  wise  to  remember  that  an  increasing  number  of  indicators  argue  in  favor  of  concurrency 
and  facilitated  interaction  between  technology  development  and  implementation  [Leonard- 
Barton,  1988a;  Orlikowski,  1992]. 

6.3.1  Codiffusion 

The  principles  of  concurrent  technology  transition  that  we  have  discussed  support  the  integra¬ 
tion  of  research,  new  product  development,  and  implementation,  making  the  concept  useful 

'^  This  is  a  problematic  issue.  Evidence  indicates  that  accelerating  technology  transition  requires  focusing  on  tech¬ 
nology  development  and  product  development  concurrently.  However,  if  there  is  no  clear  existing  or  potential 
market,  it  is  difficult  to  engage  the  interest  of  product  developers  early  in  the  technology  life  cycle.  The  question 
remains;  what  would  make  product  developers  take  the  leap  of  faith  that  they  needed  to  invest  earlier  than  they 
did? 
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for  developers  and  R&D  managers.'*^  A  similar  shared  concern  is  codiffusion — a  critical  factor 
in  the  strategic  management  of  R&D.  By  codiffusion,  we  mean  that  a  technology  may  be  dif¬ 
fused  in  relation  to  another  technology.  This  can  occur  in  a  number  of  ways: 

•  Multiple  innovations  may  spread  simultaneously  in  response  to  a  common 
need  or  market  condition. 

•  An  innovation  may  emerge  in  response  to  a  need  or  niche  created  by  an 
earlier  commodity. 

•  An  innovation  or  technology  may  connect  itself  to  or  “piggyback”  on  a 
previous  entrant. 

With  the  case  of  RMA,  codiffusion  occurred  with  Ada,  more  specifically  with  a  U.S.  Department 
of  Defense  initiative  to  mandate  use  of  the  Ada  language  for  mission-critical  software-intensive 
systems.^®  However,  the  relationship  of  RMA  to  Ada  was  more  complex:  the  association  was 
initially  an  asset,  and  then  subsequently  a  constraint.  To  understand  the  phenomenon,  we 
must  look  back  at  SEI  project  plans  for  the  emerging  technology.  In  1 989  and  1 990,  the  state¬ 
ment  of  the  project  purpose  read 

The  purpose  of  the  Real-Time  Scheduling  in  Ada  Project  is  to  transform  a  new, 
analytic  approach  for  designing  real-time  systems  into  routine  software 
engineering  practice,  particularly  for  systems  implemented  in  Ada. 

Two  years  later,  in  1991 ,  the  emphasis  on  Ada  was  found  to  be  deflecting  the  attention  of  po¬ 
tential  users  from  the  fact  that  the  theory  did  not  depend  on  Ada.  Therefore,  in  1991,  the 
project  name  changed  from  Real-Time  Scheduling  in  Ada  to  Rate  Monotonic  Analysis  for 
Real-Time  Systems.  Moreover,  linking  the  work  to  Ada  was  not  helping  to  make  the  technol¬ 
ogy  easier  to  transition;  it  tended  to  raise  questions  that  ultimately  proved  irrelevant  to  the 
adoption  process.  The  name  change  also  reflected  the  project’s  understanding  that  the  theory 
had  a  broader  range  of  application  than  was  originally  understood.  In  particular,  the  project 
came  to  realize  that  the  theory  could  be  used  to  analyze  the  behavior  of  systems  that  had  not 
been  designed  or  implemented  with  the  theory  in  mind.  In  this  sense,  the  project  was  lucky  to 
have  picked  a  theory  that  turned  out  to  apply  so  broadly.  By  1991,  the  purpose  statement  for 
the  project  had  been  tuned  to  read 

...  to  improve  the  state  of  the  practice  for  real-time  systems  engineering  by 
providing  a  solid  scientific  foundation  for  dealing  with  timing  behavior  of  real¬ 
time  systems. 

^  Funders  need  to  understand  what  development  and/or  transition  activities  they  are  funding:  where  in  the  value 
chain  or  maturation  life  cycle  the  technology  is,  what  arena  the  technology  is  intended  for,  and  what  the  relative 
cost  will  be.  (They  will  also  benefit  by  attending  to  the  issues  for  developers  described  above.)  The  example  of 
RMA  transition  does  not  provide  all  the  answers,  but  the  level  of  detail  about  types  of  activities  over  a  significant 
time  period  may  stimulate  thinking  about  requirements  for  other  technologies.  These  requirements  might  concern 
staffing,  facilities,  schedule,  and  financing. 

For  information  on  the  adoption  and  history  of  Ada,  see  Ada  Adoption  Handbook:  A  Program  Manager's  Guide 
by  W.  E.  Hefley,  J.  T.  Foreman,  C.  B.  Engle,  Jr.,  and  J.  B.  Goodenough,  1992,  Technical  Report  (CMU/SEI-92- 
TR-29,  ADA258937),  Software  Engineering  Institute,  Carnegie  Mellon  University.  See  also  Understanding  the 
Adoption  of  Ada:  A  Field  Study  Reportby  G.  N.  Smith,  W.M.  Cohen,  W.E.  Hefley,  &  D.A.  Levinthal,  1 989,  Tech¬ 
nical  Report  (CMU/SEI-89-TR-28,  ADA219188),  Software  Engineering  Institute,  Carnegie  Mellon  University. 
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Here,  rate  monotonic  scheduling  theory  is  presented  as  the  technology  of  choice  for  accom¬ 
plishing  this,  and  the  project  is  no  longer  “focused  primarily  on  scheduling  algorithms...”  be¬ 
cause  of  the  realization  that  the  theory  could  be  applied  more  widely  than  was  previously 
understood. 

The  issue  of  codiffusion  is  more  complex  than  this  brief  characterization  allows.  For  example, 
from  the  development  perspective,  codiffusion  is  often  tied  to  the  vision  for  the  technology.  We 
have  seen  how  RMARTS  articulated  its  purpose  and  the  role  of  RMA  technology.  However, 
aspects  of  codiffusion  were  influential,  as  the  project  formulated  strategies  to  achieve  the  vi¬ 
sion.  This  required  an  understanding  of  how  the  technology  began.  For  instance,  in  1988  and 
1989,  RMARTS  personnel  worked  with  engineers  outside  the  SEI  and  learned  early  about 
what  roadblocks  would  occur  when  people  tried  to  adopt  RMA  to  build  “real”  systems.  Knowl¬ 
edge  of  these  obstacles  was  subsequently  translated  into  questions  and  actions: 

•  How  would  compilers  have  to  change? 

•  Would  engineers  see  RMA  as  applicable  to  the  design  of  new  systems  and 
to  the  tuning  and  upgrading  of  old  systems? 

•  What  would  engineering  managers  need  to  know? 

Such  questions  underscore  how  codiffusion  and  standardization  issues'^  intersect  with  strat¬ 
egy.  The  vision  for  the  technology  is  only  meaningful  when  one  considers  present  conditions 
—the  status  quo— in  relation  to  a  future  state.  These  considerations  take  us,  in  turn,  back  to  a 
critical  technology  attribute  (especially  for  those  taking  a  systems  perspective):  namely,  com¬ 
patibility. 

Our  discussion  may  suggest  that  codiffusion  is  only  relevant  to  development  and  strategic 
management.  However,  this  is  not  the  case;  the  individuals  we  interviewed  at  ComCo,  Wood- 
ville  were  well  aware  of  the  early  relationship  between  real-time  scheduling,  RMA,  and  Ada.  In 
fact,  as  we  have  indicated,  it  was  this  perception  (that  RMA  was  tied  only  to  Ada)  that  prompt¬ 
ed  the  project  to  change  its  name  and  adjust  the  nature  of  the  RMARTS  purpose  statement. 
Nonetheless,  at  ComCo,  RMA  was  perceived  as  a  means  to  successfully  deal  with  Ada  sys¬ 
tems,  even  though  most  recognized  that  the  utility  of  the  analytical  approach  extended  beyond 
Ada. 

For  example,  GP,  software  engineer,  commented  that  initially  he  wasn’t  “sure  that  RMA  was 
relevant.”  He  said  they  “went  along  with  [the  change  agent]  because  they  were  one  of  the  first 
Ada  programs.  [DV’s]  model  sounded  like  it  would  give  us  insight  into  tasking  and  priorities.... 
We  were  in  the  dark  about  Ada  and  saw  this  as  a  way  to  address  tasking  problems.”  The 
system  that  GP  referred  to  was  in  high-level  design  when  it  was  determined  that  they  would 
switch  to  Ada  from  C.  GP  remarked  that  they  had  assumed  that  “they  would  get  an  Ada  waiver; 
and  they  said  ‘help’  when  they  needed  to  make  the  switch  to  Ada.”  SN,  software  engineer, 
referred  to  “one  particular  function — audio — [volume  control]  where  we  wanted  a  high-priority 

Codiffusion  and  standards  development  sometimes  blur,  so  that  the  difference  between  these  two  efforts  may 
depend  on  the  intent  of  those  who  jump  in.  For  example,  SEI  standards  work  sought  leverage  for  the  technology 
itself  and  also  sought  to  ensure  that  new  and  existing  standards  did  not  preclude  the  use  of  RMA. 
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message,  and  the  model  [RMA]  helped  us.”  SN  found  that  the  “Ada  compiler  didn’t  have  the 
interrupt  capability,  even  though  it  was  advertised  as  such.”  RB,  manager  (OCR  systems), 
succinctly  summarized  his  early  impression  of  associations  between  RMA  and  Ada.  When  we 
asked  him  if  he  had  been  able  to  observe  how  RMA  was  helpful  to  others,  he  said,  “Initially, 
no.  We  didn’t  see  its  usefulness  early  on.  We  did  not  apply  it  to  what  we  were  doing.  If  we 
weren’t  doing  a  real-time  application,  it  wasn’t  to  be  applied.  ‘I  don’t  have  a  need  because  I’m 
not  using  Ada’  was  a  typical  argument.”  Five  of  the  ten  individuals  we  interviewed  mentioned 
Ada  in  some  detail. 

6.4  Transition  Research 

The  case  study  on  the  transition  of  RMA  represents  a  single  effort  to  understand  the  complex 
processes  of  software  technology  transition  and  diffusion.  To  gain  a  full  understanding  of  this 
area,  researchers  must  consider  both  sides  of  the  technology  push-pull  equation  and  attend 
to  the  full  range  of  transfer  conditions,  from  R&D,  through  new  product  development,  to  adop¬ 
tion  and  implementation  in  an  organizational  setting.  Such  an  understanding  of  technology 
transition  requires  crossing  boundaries  between  disciplinary  communities  and  between  the 
arenas  of  academia,  industry,  and  government.  The  latter  is  a  difficult  task — each  discipline 
and  each  arena  speaks  about  and  investigates  technology  transfer  in  a  different  way  [Fowler 
&  Levine,  1993;  Rogers,  1983;  Tornatzky  &  Fleischer,  1990]. 

Additional  case  study  research  on  technology  transition  in  general  and  software  technology 
transition  in  particular  is  essential.  Researchers  must  continue  to  explore  the  circumstances 
and  surrounding  conditions  for  transferring  software  tools,  techniques,  or  practices,  as  op¬ 
posed  to  other  kinds  of  technologies.  Such  distinctions  will  become  critical  as  more  and  more 
technology  is  layered — ^and  as  software  is  embedded  within  other  technologies.  Within  the 
software  transition  arena,  researchers  must  begin  to  focus  on  a  taxonomy  of  technology  types 
and  consider  distinctions  between  tools,  techniques,  integrated  toolsets,  and  larger  ill-defined 
process-based  technologies.  Because  of  its  nature,  software  raises  fundamental  questions 
about  process-  and  product-based  technology.  Understanding  these  relationships  will  help 
create  new  taxonomies  for  technology  beyond  current  manufacturing  operation  distinctions, 
such  as  customer  technology,  small  and  large  batch,  mass  production,  etc.  [Woodward,  1965; 
Khandwalla,  1974] 

Case  study  research  can  provide  the  basis  for  understanding  software  technology  transition 
issues  generally  and  for  exploring  transition  with  respect  to  specific  technology  types  and  or¬ 
ganizational  settings.  How  does  the  transition  of  RMA  compare  to  that  of  a 

•  CASE  tool? 

•  Software  development  environment? 

•  Human  behavior-intensive  technology  such  as  software  inspections? 
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•  Tool-based  technology  such  as  project  management  that  also  requires 
human  behavioral  changes  in  attention  to  detail? 

•  Grand-scale  composite  technology  such  as  software  process  improvement? 

Finally,  how  does  the  transfer  of  these  technologies  vary  with  respect  to  the  nature  of  the  re¬ 
ceiving  organization  or  environment? 

In  exploring  these  and  other  questions,  researchers  must  be  willing  to  innovate  and  to  borrow 
methods  of  inquiry  from  the  many  disciplines  that  shed  light  on  the  process  of  technology 
transition.  For  example,  the  study  of  RMA  raises  interesting  questions  about  the  types  of 
people  involved  and  the  communities  that  they  represent.  A  full  history  and  communication- 
network  analysis  might  provide  additional  clues  to  issues  of  diffusion  and  influence. 

Case  study  research  offers  us  a  way  to  understand,  in  depth,  how  software  technologies  can 
be  effectively  (or  ineffectively)  transitioned.  Such  studies  support  the  goals  of  technology  de¬ 
velopers,  their  managers  and  funding  sources,  and  researchers  alike.  They  reflect  and  honor 
the  complexity  of  real  transition  situations,  and  also,  as  their  number  increases,  provide  a  ba¬ 
sis  for  common  understanding  of  a  range  of  transition  experience  for  software  technologies. 
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Appendix 


Interview  Questions,  ComCo,  Woodvilie 
April,  1993 

Name: 

Project: 

Job  Title: 

Job  Description: 

No.  Years  at  ComCo: 


1 .  When  did  you  first  hear  about  rate  monotonic  analysis?  Where  were  you? 
What  was  the  source? 

Did  you  hear  about  it  in  a  journal?  Specify. 

Did  you  read  about  it  in  a  ComCo  document?  Specify. 

Did  you  hear  about  it  at  an  external  event?  Specify. 

Did  you  hear  about  it  at  an  internal  event?  Specify. 

Did  you  read  about  it  on  the  Internet? 

Did  you  hear  about  it  from  a  colleague  (in  your  group,  outside  your  group, 

or  outside  ComCo)?  Specify. 

2.  When  did  you  realize  that  RMA  was  relevant  to  your  work  (to  your  problem  or 
to  your  project,  etc.)?  How  did  you  know  it  was  relevant?  What  did  you  con¬ 
sider?  (This  question  is  about  the  possibility  of  use  because  of  perceived  rel¬ 
evance.) 

3.  Were  you  able  to  observe  how  RMA  was  helpful  to  others?  (This  question  is 
about  observability.) 

4.  When  did  you  decide  to  use  RMA?  Why? 

5.  When  did  you  begin  using  RMA?  Why  then?  For  what?  How  did  you  use  it  (in 
design,  analysis,  trial  use)? 

6.  How  well  did  RMA  fit  in  with  how  you  do  your  work?  (This  question  is  about 
compatibility.) 

7.  Does  RMA  help  you  to  do  things  better  than  you’ve  done  before?  (This  ques¬ 
tion  is  about  relative  advantage.) 

8.  How  easy  or  difficult  was  it  to  use  RMA  in  your  work?  (This  question  is  about 
complexity.) 
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9.  Did  you  try  it  out?  Describe.  (This  question  is  about  trialability.) 
tO.Did  you  continue  using  RMA?  Describe. 

1 1  .Are  you  using  RMA  now?  Describe. 

12.  Will  you  continue  to  use  RMA?  Why  or  why  not? 

13.  Are  there  other  technologies  that  you’ve  explored  or  used  on  a  trial  basis? 
Specify. 

14.1s  there  anything  else  related  to  RMA  that  you’d  like  to  talk  about? 
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